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1  Introduction 

The  goal  of  this  report  is  to  present  a  formalism  which  will  provide  the  basis  for  an  imple¬ 
mentation  of  a  system  for  activity  coordination.  Our  intent  here  is  to  provide  the  intellectual 
groundwork  and  architecture  for  the  system,  rather  than  a  detailed  design.  In  this  introduc¬ 
tion  we  will  discuss  the  system  criteria  which  guided  the  development  of  the  formalism,  and 
in  subsequent  sections,  we  present  the  formalism  itself  and  show  how  a  system  based  on  it 
can  satisfy  criteria  for  the  system. 

The  overriding  requirement  for  an  activity  coordination  system  is  that  it  be  integrated 
into  the  normal  everyday  activities  of  the  people  whose  activities  are  being  coordinated. 
The  first  consequence  of  this  requirement  is  that  the  system  must,  at  a  fundamental  level,  be 
distributed.  Because  our  intended  users  are  national  organizations,  “distributed”  in  this  set¬ 
ting  means  not  only  on  local  area  networks  (where  communication  is  essentially  continuously 
available),  but  also  on  networks  where  communication  is  more  sporadic  (e.g.,  by  occasional 
dialup).  In  particular,  the  system  cannot  rely  on  any  centralized  execution  component. 

A  second  consequence  of  the  requirement  that  the  system  be  integrated  into  the  normal 
activities  of  its  users  is  that  the  system  must  be  extensible.  We  assume  that  the  normal 
activities  of  its  users  involve  contact  with  computers,  but  we  cannot  assume  much  more 
than  that — different  user  communities  will  use  different  machines  and  different  software. 
If  a  single  activity  coordination  system  is  to  be  of  widespread  use,  it  must  be  possible  to 
connect  it  to  a  variety  of  existing  software:  without  a  connection,  the  use  of  that  software 
remains  unaffected  and  thus  uncoordinated.  On  the  other  hand,  it  is  clearly  not  desirable 
for  the  activity  coordination  system  to  duplicate  functionality  of  existing  software.  Rather, 
the  system  might  control  access  to  such  software,  might  supply  some  of  its  input,  and  might 
look  at  its  output  to  assist  users  in  subsequent  parts  of  an  activity.  It  is  in  making  such 
connections  that  extensibility  is  a  prerequisite — a  closed  system  simply  will  not  be  able  to 
supply  the  necessary  degree  of  integration. 

If  an  activity  coordination  system  is  to  be  successfully  integrated  into  day-to-day  activ¬ 
ities,  it  must  be  intuitive ,  i.e.,  easily  understood  by  non-technical  users.  While  there  are 
many  factors  involved  in  making  a  system  intuitive,  we  feel  that  a  graphical  aspect  to  the 
system  is  one  of  the  most  important.  We  use  the  word  “graphical”  here  in  two  ways:  in  the 
mathematical  sense,  as  a  structure  with  nodes  and  arcs,  and  in  the  computer  system  sense, 
as  a  bit-mapped  user  interface.  The  use  of  graphs  to  describe  coordination  is  quite  com¬ 
mon:  pert  charts,  organizational  charts,  and  communication  networks  are  examples  familiar 
to  people  who  are  not  computer  experts.  And  the  use  of  graphics  by  the  best  computer 
interfaces  scarcely  needs  mention. 

It  would  be  highly  desirable  if  the  extensibility  of  the  system  could  be  accomplished,  at 
least,  in  part,  a.t,  a  very  intuitive,  presumably  graphical,  level.  This  will  not  be  possible  at 
the  low  level  of  connecting  existing  software  to  the  system,  but  it  should  be  possible  for  non¬ 
experts  to  connect  existing  pieces  together  to  provide  graph-based  high-level  descriptions  of 
activity  for  participants  of  the  system,  who  could  in  turn  understand  “what  is  happening” 
in  terms  of  these  graphs,  and  moreover,  to  be  able  to  interact  with  the  system  via  such 
graphs,  when  this  makes  sense.  Thus,  we  are  proposing  that  an  activity  coordination  system 
must  have  a  linguistic  component  that  provides  for  distributed  programs  and  yet  is  easy  to 
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understand  and  use!  We  are  aware  that  this  is  a  difficult,  if  not  impossible,  goal,  and  it  is 
only  by  restricting  the  linguistic  component  to  the  very  highest  level  that  we  have  a  chance 
of  fulfilling  it. 

Another  point  to  be  emphasized  about  the  linguistic  component  is  the  necessity  of  the 
composability  of  the  constructs  and  of  their  parameterizability.  Without  these  classic  con¬ 
cepts  from  programming  languages,  it  is  impossible  to  have  the  modularity  that  makes  it 
possible  to  reuse  existing  components  and  to  build  large  systems. 

In  addition  to  the  general  characteristics  of  distributedness,  extensibility,  and  intuitive¬ 
ness,  there  are  several  technical  issues  specific  to  the  arena  of  activity  coordination  that 
pervade  the  design  of  a  system  and  thus  the  underlying  formalism: 

•  user-interface — How  does  a  user  find  out  what  is  going  on,  and  what  is  to  be  done 
next?  How  is  this  related  to  the  description  of  the  coordination? 

•  history — How  did  the  project  get  into  its  present  state?  How  is  the  viewing  of  history 
related  to  the  user  interface  (which  usually  views  the  present)? 

•  simulation — How  might  things  go  from  here? 

•  cutover — Descriptions  of  activities  change  while  the  activities  themselves  are  under 
way.  How  can  this  be  managed? 

•  summarization — No  single  person  wants  (or  may  be  allowed)  to  see  all  of  the  informa¬ 
tion  known  to  the  activity  coordination  system.  How  can  information  be  summarized 
for  presentation  to  the  user  or  archiving  as  history? 

In  this  report,  we  shall  discuss  transaction  graphs,  a  formalism  that  provides  a  framework 
in  which  useful  solutions  to  these  problems  may  be  tailored  for  specific  applications. 
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2  Basics 

Before  giving  the  semantics  of  transaction  graphs,  it  is  necessary  to  define  their  structure. 
But  in  understanding  the  structure,  it  is  helpful  to  have  a  glimpse  of  the  key  semantic  idea: 

•  using  an  undirected  graph  with  largely  independent  computations  at  the  nodes  (cor¬ 
responding  to  “local”  activities), 

•  coupled  with  transactions  along  the  arcs  (corresponding  to  the  ways  in  which  the 
activities  interact). 

The  distributed  computation  of  an  executing  transaction  graph  is  a  machine-based  micro¬ 
cosm  of  the  real-world  activities  being  coordinated.  It  guides  the  users,  records  their  actions, 
and  presents  information  about  the  state  of  the  world. 

There  are  several  important  features  which  distinguish  transaction  graphs  from  schemes 
liko  CSP  (communicating  sequential  processes)  [Hoa84j.  First,  the  state  of  each  of  the 
computations  is  visible  in  a  controlled  way — the  visibility  of  state  provides  the  basis  for 
presenting  information  to  the  users  of  the  system.  Second,  the  use  of  transactions  (which  will 
be  explained  in  section  2.2)  seems  to  provide  a  better  basis  for  activity  coordination  than 
mere  message  passing,  because  it  more  succinctly  constrains  the  behavior  of  the  involved 
computations.  Further,  limiting  the  transactions  to  those  that  take  place  in  a  specified 
graph  guarantees  a  simple,  intuitive  means  of  depicting  patterns  of  communication. 

2.1  Structure 

We  begin  the  discussion  of  the  structure  of  a  transaction  graph  with  the  definition  of  a 
signature ,  which  is  written  a  bit  like  a  procedure  header: 

•  («i  : pi,  nk  :  pk) 

-  The  n;  are  distinct  symbols. 

-  The  pi  are  protocols,  drawn  from  a  set  P. 

As  we  will  see,  such  a  signature  describes  a  node,  and  each  n,  :  pt  is  associated  with  one  of  its 
k  adjacent  arcs.  The  symbol  n,  is  the  name  of  the  arc  relative  to  the  node,  and  pi  describes 
behavior  on  the  arc  from  that  node’s  point  of  view.  We  will  assume  a  “transposition” 
operation  which  takes  a  protocol  and  produces  a  protocol  for  the  other  end  of  the  arc: 

•  T  :  P  —>  P,  where  pTT  —  p,  for  all  p  €  P. 

Perhaps  the  simplest  example  of  a  protocol  set  is  one  that  directs  an  arc:  P  =  {0,  l},  where  0 
means  an  incoming  directed  arc  and  1  means  an  outgoing  directed  arc.  In  this  case,  O7  =  1. 
Another  example  of  a  set  of  protocols  can  be  constructed  from  the  set  of  types  U,  where  we 
let  P  =f  [/  x  U ,  i.e.,  a  protocol  is  a  pair  of  types,  ( ti,t[ ),  meaning  that  the  node  will  make 
visible  a  value  of  type  tt,  and  will  see  a  value  of  type  t[  made  visible  by  its  neighbor  along 
that  arc.  In  this  example,  we  naturally  have  {t„t',)T  =  (<(,£,).  As  we  will  see,  protocols  may 
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also  specify  aspects  of  the  behavior  along  the  arc  (as  the  name  “protocol”  suggests),  not  just 
the  types  of  values. 

A  transaction  graph  is  an  ordinary  undirected  graph,  except  that  it  is  allowed  to  have 
dangling  arcs  (ones  that  do  not  attach  to  another  node).  Such  a  graph  is  labeled  in  the 
following  way: 

•  Each  node  is  labeled  with  an  activity  description ,  consisting  of  several  components, 
one  of  which  is  a  signature. 

•  Each  non-dangling  arc  is  labeled  with  two  names,  one  each  from  the  signatures  asso¬ 
ciated  with  the  nodes  at  its  ends.  Pictorially,  the  name  appear?-  near  the  node  whose 
activity  description  has  the  signature  in  which  it  appears. 


•  Each  dangling  arc  is  also  labeled  with  two  names,  one  from  the  signature  of  the  activity 
description  on  the  nMc  to  which  the  arc  is  attached  (this  "ame  appears  near  the  node), 
and  another  “graph-relative”  name,  appearing  at  the  dangling  end  of  the  arc. 

•  At  every  node,  each  name  in  the  signature  of  the  activity  description  appears  exactly 
once  as  the  “near”  label  of  an  incident  arc. 

•  A  graph-relative  name  appears  on  only  one  (dangling)  arc. 

•  Let  ni  and  n2  be  the  labels  on  a  non-dangling  arc,  and  let  n,-  :  p,-  appear  in  the 
respective  signatures.  Then  pi  =  pj  (equivalently,  pf  =  p2).  This  is  called  the  protocol 
conformance  rule. 

The  last  rule  here  is  analogous  to  a  rule  found  in  many  ordinary  programming  languages 
for  type  conformance  between  actual  and  formal  parameters  of  a  function.  Continuing  our 
example  of  protocols  as  pairs  of  types,  if  p,  =  then  the  protocol  conformance  rule 

says  that  t\  =  t'2  and  t[  =  t2. 

We  close  this  section  by  introducing  some  notation  and  a  definition  that  will  be  used 
throughout. 

•  Nodes  will  usually  be  denoted  by  the  letter  u ,  and  arcs  by  the  letter  a;  in  each  instance, 
subscripts  are  common. 

•  If  arc  a  is  incident  on  the  node  u ,  the  name  on  a  near  u  is  n„>0,  the  corresponding 
protocol  from  the  signature  of  the  activity  description  on  u  is  pu>a,  and  the  opposite 
end  of  a  from  u  will  be  denoted  u/a. 

•  If  a  is  a  dangling  arc,  then  u0  is  the  (unique)  node  upon  which  a  is  incident,  and  na  is 
the  graph-relative  name  on  a. 

•  The  signature  of  a  graph  defined  to  be  ( na  :  pU(IIo)a,  where  a  ranges  over  all  dangling 
arcs. 
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2.2  Execution 

“Execution”  will  be  defined  for  transaction  graphs  with  no  dangling  arcs.  The  first  step  is 
to  describe  another  component  of  an  activity  description  d  (in  addition  to  its  signature): 

•  An  activity  description  d  has  an  associated  set  of  states  Sd • 

•  In  a  transaction  graph,  we  shall  use  the  convention  that  <SU  denotes  Sd  where  d  is  the 
label  of  u. 

•  The  set  of  states  for  a  transaction  graph  is  defined  to  be  Xu«?u,  where  u  ranges  over 
the  nodes  of  the  graph. 

An  execution  of  a  transaction  graph  consists  of  a  sequence  of  states  for  the  graph,  constrained 
by  rules  given  below.  The  rules  involve  not  only  states,  but  elements  of  the  following: 

•  There  is  a  set  of  values  V  that  are  seen  along  arcs. 

Each  of  the  next  two  components  of  an  activity  description  is  a  set  of  functions  involving  Sd 
and  V.  The  first: 

•  Let  activity  description  d  have  signature  (n,- :  There  are  functions: 

:  Sd  -+  V 

Intuitively,  <Td,i  reveals  part  of  the  state  of  a  node  labeled  with  d  to  the  ith  neighbor. 

The  second  set  of  functions  formalizes  what  happens  at  a  transaction.  In  essence,  a  node 
can  change  the  value  it  makes  visible  along  one  arc  at  a  time,  based  on  its  own  state  and 
that  of  its  neighbor  along  the  arc.  In  conjunction  with  this  operation,  it  can  change  its  own 
state.  For  reasons  we  discuss  below,  the  state  change  is  non-deterministic. 

•  Let  d  have  signature  (n,- :  p,-),-.  There  are  functions: 

Td,i :  Sd  X  V  — >  2Sd  where  for  all  s,v,s'  €  Td,i(s,v)  and  j  ^  i :  crd,j(s)  =  ad,j{ s ') 

Intuitively,  Ta<i  looks  at  the  node’s  own  state  (in  Sd)  and  the  value  (in  V)  exposed  by  the 
neighbor  along  the  tth  arc,  and  comes  up  with  a  new  state  (an  element  of  25d).  The  condition 
says  that  the  state  change  can  affect  only  the  value  along  the  arc  where  the  transaction  occurs. 

The  final  component  of  an  activity  description  corresponds  to  an  out-of-graph  state 
change,  i.e.,  one  not  involving  a  transaction.  Out-of-graph  state  changes  correspond  ei¬ 
ther  to  real  world  events  like  the  passage  of  time,  or  to  changes  not  modeled  at  a  particular 
level  of  graph  structure. 

•  Let  d  have  signature  (n,-  :  /?,•);.  There  is  a  function: 

Od'  Sd  — >  25d  where  for  all  s,s'  €  Od(s)  and  i:  crd,i(s)  =  ^-(s') 
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The  condition  says  that  exposed  values  do  not  change  without  a  transaction,  i.e.,  an  appli¬ 
cation  of  Td,i  for  some  i. 

Before  we  can  proceed  to  the  definition  of  execution,  there  is  one  last  bit  of  groundwork, 
concerning  how  protocols  play  a  role.  The  idea  is  that  a  protocol  is  a  validation  predicate 
on  the  sequence  of  values  seen  along  an  arc.  Since  values  seen  along  the  arc  can  appear  at 
either  end,  we  formalize  the  sequence  as  pairs  {{/,-,  u, •)),•,  where  /,•  €  {0, 1} ;  /<  intuitively  says 
which  end  the  value  V{  is  exposed  on.  By  convention,  /,*  =  0  means  that  vt  is  exposed  by  cr,, 
and  thus  /,•  =  1  means  that  vt-  is  seen  by  r,-.  Using  S*  to  denote  the  set  of  all  sequences  of 
elements  of  a  set  S,  we  require  that: 

•  An  element  of  P  is  a  predicate  on  ({0, 1}  x  Vr)". 

The  spirit  of  transaction  graphs  is  that  values  are  seen  along  arcs,  not  necessarily  transmitted, 
and  in  this  spirit,  an  element  of  P  is  allowed  to  pass  judgment  only  on  the  sequence  of  changes 
to  exposed  values.  This  can  be  technically  stated  as  follows: 

•  Let  ((/i, Uf))j  €  ({0,1}  x  F)*,  and  suppose  there  are  some  z'i  and  i 2  with  /,■  ^  for 
i\  <  i  <  z2,  i.e.,  there  is  no  change  in  the  value  seen  at  the  eud  of  the  arc.  Then 
repeating  ,  u,-,  after  changes  at  the  /,-2  end  of  the  arc  does  not  affect  the  value  of  the 
protocol,  or  technically,  every  p  €  P  must  satisfy: 

P(«/»» ».*)).•)  ?(((/*» Vi »,•*((/«•„ o.'i))) 

In  practice,  we  define  the  action  of  a  protocol  as  a  predicate  only  for  reduced  sequences, 
by  which  we  mean  sequences  with  the  property  that  if  i\  and  z2  are  successive  indices 
with  the  same  /,-,  then  u,-,  ^  u,-2. 

The  action  of  p  €  P  as  a  predicate  must  have  a  proper  interaction  with  the  transposition 
operator  on  P: 

•  For  all  p  €  P  and  ((/,-,  «<)},•:  p(((/;,  vi))i)  &  PT(((1  ~  /<,«»•))*) 

In  our  running  example  of  a  protocol  as  a  pair  of  types  we  would  define  (to,ti)  to  be 

true  of  a  sequence  ((/j,v<))»  if  vi  h35  lyPe  ^ /, >  for  all  i.  The  point  of  saying  that  an  element 
of  P  is  a  predicate  on  a  sequence  of  seen  values  is  that  it  can  thus  be  used  to  specify  the 
communication  pattern  that  must  be  obeyed  along  the  arc,  not  merely  the  static  properties 
of  individual  values. 

We  shall  use  the  convention  that  rUja  denotes  r^j,  where  d  is  the  label  of  node  u,  and  a 
is  the  zth  arc  incident  upon  u.  Similarly  for  aUA. 

•  Given  a  state  of  a  transaction  graph,  a  subsequent  state  is  one  which  differs  at  exactly 
one  node  u,  where  the  new  state  at  u  is  an  element  of: 

0u($u)  u  (_J  TU)( ,  (su,  cru/a>a(su/a)) 

a 

Here,  su  and  su/a  are  states  of  nodes  from  the  given  graph  state,  and  a  ranges  over 
arcs  incident  upon  u. 
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Finally,  an  execution  is  a  sequence  of  graph  states,  in  which: 

•  Each  state  but  the  first  is  subsequent  to  the  previous  element  in  the  sequence. 

•  On  any  arc,  the  values  exposed  along  that  arc  satisfy  the  protocol  on  the  arc. 

Note  that  this  definition  implies  that  changes  at  nodes  occur  serializably — execution  does 
not  allow  the  two  nodes  on  an  arc  to  change  simultaneously,  i.e.,  two  new  exposed  values 
cannot  be  based  on  two  old  exposed  values. 

We  promised  earlier  some  justification  for  the  role  of  non-determinism.  The  first  and 
foremost  reason  is  that  non-determinism  is  part  of  the  reality  that  transaction  graphs  are 
designed  to  help  cope  with.  Especially  because  of  the  modeling  and  summarizing  role  of 
applications,  there  is  a  necessity  that  the  underlying  formalism  address  non-determinism  in 
a  fundamental  way.  We  will  also  see  various  technical  conveniences  of  this  formalization,  such 
as  the  following:  how  do  we  know  when  execution  of  a  transaction  graph  is  finished?  After 
all,  the  computational  model  here  is  quite  distributed  (as  promised):  there  is  no  obvious 
“exit  node”,  and  specifying  one,  and  its  behavior,  would  be  artificial,  beneath  the  level  of 
the  rest  of  the  above  formulation.  Rather,  the  fact  that  t  and  o  specify  a  set  of  states  allows 
for  a  natural,  distributed ,  termination  condition. 

0  =  U(^u(^u)  U  (_J  'Tu1a('Su>  Ou/a.a^u/a))) 

ti  o 

Obviously,  an  execution  sequence  stops  once  this  condition  holds.  We  shall  see  other  technical 
conveniences  of  non-determinism  in  later  sections. 

Even  though  this  paper  does  not  directly  address  implementation  concerns,  we  should 
note  that  an  implementation  of  r  does  not  actually  produce  a  set  of  states;  rather,  it  even¬ 
tually  picks  one  state  that  is  a  member  of  the  set  produced  by  the  theoretical  r.  Thus,  the 
definition  of  r  serves  as  a  specification  for  the  implementation  rather  than  a  prescription. 
(However,  it  may  well  be  useful  to  implement  the  predicates  Td,i(s,v)  =  0  and  Od[s)  =  0.) 
Similarly,  we  do  not  propose  literally  implementing  the  predicate  corresponding  to  an  element 
of  P.  This  too  serves  as  a  specification. 

In  the  previous  section,  we  saw  that  an  activity  description  had  a  signature,  and  that 
there  was  a  transposition  operator  on  the  protocols  in  signatures.  These  were  necessary 
to  specify  well-formedness  of  transaction  graphs.  In  this  section,  we  added  the  following 
semantic  notions,  necessary  in  the  definition  of  execution. 

•  For  activity  description  d,  whose  signature  is  ( rii  :  p,)j,  there  are  also  the  following 
componentc. 

—  A  set  of  states  Sd- 

-  A  lrt  of  maps  <7^,- :  Sd  — *  V  revealing  part  of  a  state  to  a  neighbor. 

-  A  list  of  maps  Td,i :  Sd  x  V  — ►  25d,  corresponding  to  transactions  along  an  arc. 

-  A  map  Od  :  Sd  —>  2Sd,  corresponding  to  out-of-graph  state  changes. 

•  Each  element  of  P  acts  as  a  predicate  on  values  seen  along  an  arc.  The  action  as  a 
predicate  is  well-behaved  with  respect  to  transposition  on  P. 
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We  close  this  section  by  emphasizing  the  distributedness  of  the  computational  model,  i.e., 
its  suitability  to  a  truly  distributed  implementation.  There  is  no  assumption  of  scheduling 
here,  only  that  two  adjacent  nodes  racing  to  perform  a  transaction  on  their  common  arc 
can  decide  who  goes  first.  It  may  seem  odd  that  when  concurrency  is  the  goal,  transactions 
around  a  node  must  occur  one  at  a  time,  but  this  is  only  the  way  that  one  says  formally 
that  transactions  are  serializa&fe,  not  that  the  implementation  is  required  to  perform  them 
serially.  Moreover,  this  approach  to  the  formalism  has  the  advantage  of  minimizing  the 
machinery  in  the  system,  and  maximizing  the  flexibility  one  has  in  making  extensions,  i.e., 
implementing  functions  specified  by  <7,  t,  and  o.  This  extends  even  to  concepts  that  are 
often  built  into  the  semantics  of  a  distributed  system,  for  example,  fairness  in  scheduling. 

2.3  Graphical  Condensation 

In  this  section,  w.;  will  show  that  there  is  a  natural  way  to  define  an  activity  description  that 
mimics  the  beha.’io:  of  a  transaction  graph.  This  technique  of  shifting  complexity  between 
the  graph  structure  and.  the  activity  descriptions  has  several  important  consequences.  Most 
obviously,  it  means  tliai  transaction  graphs  can  be  specified  hierarchically — one  can  place  a 
node  in  a  graph,  much  in  the  same  manner  that  one  writes  a  subroutine  and  refers  to  it  by 
name. 

Less  obviously,  graphical  condensation  is  related  to  obtaining  different  views  of  an  ac¬ 
tivity,  in  the  following  way.  Given  a  subgraph  of  a  graph,  that  subgraph  may  be  collapsed 
to  a  node  as  a  way  of  summarization,  in  other  words,  a  particular  view  of  an  activity  may 
involve  a  particular  condensation  of  certain  aspects  of  the  graph  structure.  A  second  view 
may  condense  a  different  subgraph,  perhaps  partially  overlapping  the  first  view.  Thus  the 
same  activity  may  be  viewed  as  occurring  on  quite  different,  not  even  hierarchically  related, 
graphs. 

To  be  precise,  we  will  define  the  induced  activity  description  for  a  transaction  graph 
from  the  components  of  the  activity  descriptions  on  the  nodes  of  the  transaction  graph,  and 
of  course,  from  the  connectivity.  Consider  two  graphs,  one  with  a  node  labeled  with  the 
activity  description  induced  from  a  graph,  and  one  with  the  node  replaced  by  the  graph 
from  which  it  was  induced.  The  result  will  be  that  the  execution  of  the  two  graphs  are  in 
1-1  correspondence. 

The  following  subsections  will  discuss  graph  condensation,  in  each  case  giving  induced 
activity  descriptions  and  a  proof  of  the  1-1  correspondence  of  executions.  There  are  two 
transformations,  which  together  are  sufficient  to  condense  a  graph  to  a  node. 

2.3.1  Pinching  Two  Nodes 

In  this  subsection  we  consider  the  induced  activity  description  for  the  graphical  operation  of 
“pinching”  two  nodes,  i.e.,  replacing  them  with  a  single  node,  and  attaching  arcs  that  used  to 
be  incident  upon  either  node  to  the  new  node.  In  its  simplest  form,  the  graph  transformation 
is: 
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On  the  left  is  a  transaction  graph  consisting  of  two  unconnected  nodes;  on  the  right  is  a 
transaction  graph  consisting  of  a  single  node,  having  arcs  corresponding  to  the  arcs  on  the 
left,  i.e.,  labeled  in  the  same  way  (with  graph-relative  and  node-relative  names). 

We  first  consider  the  signature  for  the  new  activity  description  d0.  Let  (riji:  :  pj{}  )tj ,  be 
the  signature  for  dj.  We  will  assume  that  the  sets  of  names  are  distinct,  i.e.,  nu,  ^  n2,-2 ,  for 
any  i\  and  i2;  if  not,  they  may  be  renamed.  Since  we  are  trying  to  arrange  that  both  graphs 
appear  the  same  on  the  outside,  they  at  least  have  to  have  the  same  signature,  which  forces 
the  signature  of  do  to  be  defined  as: 

(nn  :  pu, . . . , nut,  :  pu-, , n2 1 :  P21, . . . ,  n2jt2  :  P2k2) 


Next,  consider  the  set  of  states.  If  the  two  graphs  behave  the  same,  then  in  general  we 
would  have  to  have  to  define  Sdo  to  be  Sdi  x  Sd2 .  Similarly,  identical  behavior  requires: 


•  <7d0li«si>s2))d=  | 

•  ^0>i((5i,52),v)d= 


<rdui{s  1)  iii<h 

Vdij-kM  otherwise 

f  Trflli(s,,u)  x  {s2} 

I  M  x  Td2ii_kl(s2,v) 


if  i  <  ki 
otherwise 


•  odo((s1,s2))  =f  od,(si)  x  {s2}  U  {s^  x  od2(s2)- 
This  effectively  defines  the  desired  activity  description  do,  which  we  will  call  di  x  d2. 


Result  1  Suppose  we  have  two  nodes  U\  and  u2  of  a  transaction  graph,  with  activity  de¬ 
scriptions  dti  and  that  we  obtain  a  new  transaction  graph  by  pinching  them  into  a  single 
node  u0  which  we  label  with  d\  x  d2.  Then  there  is  a  1-1  correspondence  between  executions 
in  the  two  graphs. 

Proof  The  “correspondence  between  executions”  can  be  made  precise  only  by  first  being 
precise  about  the  correspondence  between  states.  In  the  two  graphs,  the  states  are  given  by 
the  following  respective  sets: 


X  Su  and  (  X  Su )  x  SUo 

U  U^U,  ,u2 

But  <SUo  =  Su j  x  SU2 ,  so  there  is  a  clear,  correspondence  between  states,  which  involves  only 
re-ordering  and  restructuring  tuples. 

(...si...$2...)  «->  ( . (si,s2» 
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With  this  correspondence  of  states,  it  is  clear  from  the  definition  of  crUo  and  the  fact  that 
<rU|.  is  unchanged  for  i  ^  1  or  2,  that  at  corresponding  states,  the  same  values  are  exposed 
at  the  corresponding  ends  of  all  arcs. 

The  key  to  the  argument  is  to  look  at  the  possible  subsequent  states  of  corres  ending 
states.  For  any  subsequent  map  in  the  “before”  graph  which  differs  at  a  node  other  than 
or  u2,  there  is  trivially  a  subsequent  map  in  the  “after”  graph  differing  at  a  node  other  than 
u o,  and  vice  versa.  If  the  change  occurs  at  u*,  changing  s;  to  s[,  there  will  be  a  subsequent 
map  for  the  “after”  graph  in  which  (si,  s2)  is  changed  to  (5,1,s2)  or  (si,s'2).  Conversely,  any 
change  at  u0  will  be  of  this  form,  and  thus  there  will  be  a  corresponding  subsequent  state  in 
the  “before”  graph.  In  short,  there  is  a  1-1  correspondence  between  subsequent  states,  and 
hence  a  1-1  correspondence  between  executions. 

□ 

Define  two  activity  descriptions  to  be  equivalent,  denoted  =,  if  they  have  the  same  signature, 
if  there  is  a  1-1  correspondence  between  states,  and  if  under  this  correspondence,  r,  a  and  o 
are  all  equivalent. 

Result  2  di  x  d2  =  d2  x  di  and  ( d\  x  d2)  x  d3  =  di  x  [d2  x  da) 

Proof  In  the  first  case,  the  correspondence  between  states  is  that  between  Sdl  x  Sd2  and 
$d2  x  £<*,,  the  details  of  the  proof  are  not  worth  writing.  In  the  second,  we  use  associativity 
of  cartesian  products  to  get  correspondence  of  states,  and  give  the  proof  for  o. 

°{d\  xd2)xd3{{{sl  i  S2))  ^3)) 

=  0d,xd2((si,s2))  X  {s3}  u  {{si,s2)}  x  0d3{s3) 

=  ( odl(si )  X  {<s2}  U  {S!}  X  Od2(s2))  x  {s3}  u  {(si,s2)]  X  Orf3(s3) 

=  odl(si)  x  {s2}  x  {s3}  U  {si}  x  od2(s2 )  x  {s3}  U  {sj  x  {s2}  x  orf3(s3) 

Starting  from  OdlX(d2xd3)>  we  get  the  same  expression.  Details  for  cr  and  r  are  omitted. 

□ 

To  summarize  this  section,  we  have  shown  that  given  any  transaction  graph  G ,  we  can 
construct  a  graph  with  a  single  node  whose  execution  is  essentially  the  same  as  that  of  G. 
The  activity  description  for  this  node  is  given  by: 

X  du,  where  du  denotes  the  activity  description  that  G  assigns  to  u 
«6G 

By  the  preceding  result,  the  order  in  this  product  doesn’t  matter. 

2.3.2  Shrinking  Loops 

While  the  techniques  of  the  previous  section  condense  an  arbitrary  transaction  graph  to  one 
having  only  a  single  node,  the  activity  description  for  that  node  is  not  what  we  want  to  call 
“the”  activity  description  for  the  graph,  because  the  pinching  process  leaves  arcs  both  of 
whose  ends  are  incident  upon  the  single  node;  such  arcs  are  called  loops.  Because  pinching 
nodes  does  not  affect  the  set  of  arcs,  there  will  in  fact  be  one  loop  on  the  single  node  for  every 
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non-dangling  arc  in  the  original  graph.  In  this  section,  we  consider  the  graph  transformation 
of  removing  a  loop. 


The  reason  for  the  terminology  “shrinking”  is  that  while  from  the  standpoint  of  only  the 
graph  structure,  it  looks  as  if  the  loop  is  simply  being  removed,  from  the  point  of  view  of  the 
activity  descriptions,  the  semantics  for  the  loop  is  being  pulled  inside  the  node,  i.e.,  turned 
into  an  out-of-graph  change  of  state. 

Let  d  have  signature  (n,-  :  p,),-.  For  convenience,  we  will  assume  that  the  loop  has  node¬ 
relative  names  n\  and  n2,  so  that  the  signature  for  d'  is  (n,  :  pi)i>2.  We  naturally  define  S# 
to  be  <S</,  and  carry  over  the  definitions  of  cr^it  and  for  i  >  2.  The  only  non-trivial  part 
of  the  construction  is  that  what  were  previously  transactions  along  the  loop  must  become 
out-of-graph  changes,  as  seen  in: 

«  od,(s)  =f  od(s)  U  rdil(s,<r<ii2(s))  U  t^s,^^)) 

This  completes  the  definition  of  d\  which  we  denote  by  d  -  [1,2];  more  generally  we  give  the 
pair  of  indices  removed.  We  will  also  use  the  notation  d  —  a  when  it  is  understood  that  the 
indices  arise  from  an  arc  a  that  is  a  loop  at  a  node  labeled  by  d. 


Result  3  Suppose  a  node  u  of  a  transaction  graph  is  labeled  by  d  and  has  a  loop  a,  and 
that  we  obtain  a  new  transaction  graph  by  removing  arc  a  at  u  and  replacing  the  label  with 
d  —  a.  Then  there  is  a  1-1  correspondence  between  executions  in  the  two  graphs. 


Proof  Unlike  the  case  in  the  previous  subsection,  here  the  sets  of  states  are  identical.  For 
subsequent  states  that  differ  at  a  node  other  than  u ,  the  correspondence  is  immediate,  as 
is  the  case  of  u  when  the  state  change  is  due  to  a  transaction  along  an  arc  other  then  a. 
The  remaining  state  changes  at  u  in  the  “before”  graph  are  either  out-of-graph  changes,  or 
transactions  along  a,  all  of  which  correspond  to  out-of-graph  changes  at  the  corresponding 
node  of  the  “after”  graph,  and  conversely.  Thus  there  is  a  1-1  correspondence  in  subsequent 
states. 

□ 

Not  only  does  the  order  of  shrinking  arcs  not  matter,  but  the  operation  “commutes”  with 
pinching: 


Result  4  Let  z'i,  i2,  z-3  and  z4  be  distinct  indices  of  the  signature  of  an  activity  description 
d.  Then: 


{d-  [*J,*2])  -  [*3,  U]  =  (c?  —  [«3,  -  [*1,»2] 
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Result  5  Let  i\,i2  be  distinct  indices  of  di,  and  let  d2  be  an  activity  description.  Then: 


(di  -  [*1,12])  x  d2  =  (d\  x  d2)  -  [ii,i2] 

(The  notation  here  assumes  that  signature  indices  of  di  correspond  to  indices  for  the  “ di 
part”  of  di  x  d2.) 

Proof  In  both  cases,  the  signatures  are  the  same,  as  are  the  set  of  states  and  the  actions  of 
cr  and  t.  In  the  first  result,  the  expression  for  o  for  the  left  hand  activity  description  expands 
out  to: 

(<>^(5)  U  Tdth(s,adti2(s))  U  Td>i2(s,adlil(s)))  U  Td<{i(s,  <rdtit  (s))  U  Td<it(s,  <rd,i3{s)) 

The  right  hand  activity  description  expands  out  to  a  similar  expression  with  i\  and  i-L  ex¬ 
changed  with  iz  and  i\  respectively.  So  the  result  follows  by  commutativity  and  associativity 
of  “U”. 

In  the  second  result,  the  computation  is  messier,  but  for  completeness,  here  it  is: 


°(<h-[«'i,i2])xd2((si,s2)) 

=  ^j-lu^lCsi)  x  {^2}  U  {si}  x  oj2(s2) 

=  (orf1(si)Ur(ili,1(si,crrflit-2(s1))Ur(il);2(si,(7dlij1(s1)))  x  {s2}  U  {sj  x  od2(s2) 

=  odl(s  1)  x  {s2}  U  {si}  x  od2(s2)  U  r(fllf,(s1,<rrfl);2(si))  x  {s2}  U  x  {s2} 

=  OdjXd2((s1,S2))UTdlXd2til((s1,S2),(TdlXd2>i2((si,S2)))UTdiXd2ti3((s1,S2),(TdlXd2>ij((si,S2))) 

=  °diXd2-(ii,»2]((5l,52)) 

In  the  “=”  step,  we  are  using  the  fact  that  since  i\  and  i2  are  indices  for  d\,  Tdlit(si,  u)  x  {s2}  = 
Tdixd2,i({s i>52),u),  for  i  =  i\  and  i2,  and  similarly  for  adu{. 

□ 

From  the  first  of  these  results,  we  can  use  the  notation  d  —  {[ij,i'j]}j  to  mean  d  -  [ii,^]  — 
[i2,i 2]  —  . . .,  because  the  order  doesn’t  matter.  Similarly,  if  {a,},  is  a  set  of  arcs,  we  can  use 
the  notation  d  —  {a,},-  without  ambiguity. 

With  these  results,  it  is  possible  to  condense  an  arbitrary  transaction  graph  G  to  a  graph 
with  a  single  node  and  only  dangling  arcs,  and  having  essentially  the  same  execution  as  G. 
The  activity  description  on  the  single  node,  which  we  call  the  activity  description  induced 
by  G,  is  given  by: 

dG  =  X  du  —  {«  €  G  |  a  is  non-dangling} 

ueG 

In  many  respects,  the  ability  to  obtain  an  activity  description  that  corresponds  to  a  graph 
dictated  the  technical  details  of  the  definition  of  an  activity  description.  For  example,  sup¬ 
pose  that  we  had  defined  an  activity  description  to  allow  simultaneous  change  of  exposed 
values.  Then  there  would  be  a  class  of  activity  descriptions  which  could  rrot  be  realized  as 
transaction  graphs.  Or  suppose  that  we  had  not  allowed  out-of-graph  changes  to  the  state. 
Then  transaction  graphs  would  not  be  closed  under  the  shrinking  of  loops. 
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In  summary  of  these  first  two  subsections,  we  have  seen  that  the  definition  of  activity 
descriptions  and  transaction  graphs  is  done  in  such  a  way  that  the  complexity  of  a  transaction 
graph  can  be  traded  off  against  the  complexity  of  the  state  of  its  nodes.  There  is  nothing 
about  the  behavior  of  an  activity  description  that  is  particularly  different  from  the  behavior 
of  a  transaction  graph;  in  other  words,  there  is  no  particular  aspect  of  behavior  that  must 
be  put  into  a  graph,  or  must  not  be  put  into  a  graph.  We  believe  that  this  property  enables 
the  construction  of  a  layered  system  of  activity  descriptions  with  clean  encapsulation. 

2.4  Projected  Execution 

In  viewing  an  ongoing  activity,  it  is  important  to  be  able  to  select  only  part  of  the  informa¬ 
tion  that  is  necessary  for  the  execution  of  the  transaction  graph  as  a  whole.  Naturally,  which 
information  is  selected  depends  upon  the  view  in  question.  The  goal  of  this  section  is  to 
structure  the  selection  of  information  in  such  a  way  that  a  view  makes  sense  on  its  own.  The 
technical  approach  is  to  require  that  the  state  changes  seen  in  the  view  are  actually  an  exe¬ 
cution  in  a  transaction  graph  that  is  related  in  some  well-understood  way  to  the  transaction 
graph  being  viewed.  Thus,  where  in  the  previous  section  we  studied  transformations  with 
1-1  correspondence  in  executions,  here  we  are  interested  in  transformations  which  have  the 
property  that  for  every  execution  in  the  original  transaction  graph  (the  one  being  viewed), 
there  is  an  execution  in  the  transformed  transaction  graph  (the  view),  but  not  necessarily 
vice-versa.  That  is,  the  set  of  executions  in  the  view  contains  (and  may  greatly  exceed)  those 
in  the  original  graph.  This  is  because  of  the  loss  of  information  in  the  transformed  graph, 
which  causes  an  increase  in  the  non-determinacy  of  cr ,  r  and  o. 

In  further  contrast  to  the  previous  section,  there  we  always  changed  the  graph  structure, 
but  kept  1-1  correspondence  in  the  states.  Here,  it  suffices  to  keep  the  graph  structure  the 
same,  and  change  only  the  activity  descriptions  on  nodes.  Imagine  two  copies  of  the  same 
graph  structure  (not  transaction  graphs,  yet),  one  drawn  in  a  plane  directly  above  the  other. 


Turn  each  of  these  graphs  into  a  transaction  graph  by  assigning  an  activity  description  to 
each  node.  Further,  assign  a  state  to  each  node,  where  the  states  on  each  of  the  planes 
together  make  up  the  state  of  an  execution  going  on  in  that  plane.  The  bottom  plane  we 
will  view  as  the  detailed  execution,  and  the  top  plane  as  a  view  on  the  detailed  execution — a 
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“filter”  through  which  we  look  at  the  “real”  execution.  This  view  is  formalized  as  a  projection 
mapping  the  bottom  to  the  top  plane,  where  this  projection  behaves  “properly”  (one  might 
say  homomorphically)  with  respect  to  the  functions  <7,  r,  and  o. 

The  essence  of  the  subject  here  is  maps  from  one  activity  description  to  another.  We  will 
denote  such  maps  with  II,  and  by  abuse  of  notation,  also  use  II  for  the  map  of  constituent 
parts  of  an  activity  description.  A  map  II  must  have  the  following  constituents: 

•  A  map  that  takes  signatures  to  signatures:  (n,-  :  p,),- i->  (?i;  :  II;(p,-))» 

•  A  map  that  takes  a  state  to  a  state:  II :  Sd  — *  <Sn(d) 

•  Maps  for  values  seen  along  an  arc:  v  >->  n,-(u) 

•  Maps  (functionals)  taking  cr^i  *->  0Tl(e/),i,  rd,i  ^  Tn(d),i,  and  od  i->  o11((i) 

We  are  interested  only  in  the  subset  of  such  maps,  for  which  we  use  the  term  projections , 
that  have  the  properties  given  below.  In  stating  these  properties,  we  further  abuse  II  by 
applying  it  to  subsets  of  Sd,  by  which  we  mean  the  subset  of  <Sn(</)  obtained  by  applying  II 
to  elements  of  the  given  subset. 

•  For  all  s  €  Sd,  Ui(<7dii(s))  =  <7npo..-(n(s)) 

•  For  all  s  €  Sd,v  €  F:  II (rd>,-(s, t>))  C  itya)., -(11(a), Hf(u)) 

•  For  all  s  €  Sd :  n(oeJ(u))  G  on(<i)(n(s)) 

The  “C”  in  each  of  the  last  two  conditions  make  precise  the  ways  in  which  11(d)  may  lose 
information  present  in  d. 

In  addition  to  homomorphic  behavior  at  each  node,  we  need  a  similar  condition  for  what 
happens  on  an  arc: 

•  Let  II  be  a  projection  of  signatures,  and  let  IIo  and  III  be  projections  of  values.  We 
say  that  IIo  and  III  are  consistent  with  II  at  p  ^  for  any  sequence  of  values 

In  other  words,  IIo  and  IIj  project  a  legal  sequence  of  values  to  a  legal  sequence  in  the 
view. 

This  property  is  used  in  the  definition  of  a  projection  of  a  transaction  graph  G,  which  is  a 
set  of  projections  IIU,  one  for  each  node  of  G,  with  the  properties: 

•  Replacing  the  label  du  on  node  u  with  Ilu(c/u),  for  all  u  G  (?,  results  in  a  transaction 
graph,  i.e.,  one  in  which  the  ruie  for  signatures  is  met.  (In  other  words,  if  U\  and  112 
are  connected  by  arc  a,  and  if  tt,  has  protocol  p,  on  a  (so  p\  =  p2 )>  then  IIUlia(rf)  = 
nu2,a(p2)-) 

•  For  every  arc,  the  projections  of  the  values  at  the  ends  of  the  arc  are  consistent  with 
the  projection  of  the  protocol  on  the  arc. 
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Again  overloading  II,  let  11(G)  be  a  projection  of  a  transaction  graph  G,  and  for  any  state 
{su}u€G  for 

•  Let  n({su}u€G)  =f  {nu(su)}u6G 

Finally,  we  need  to  define  what  it  means  to  project  an  execution  of  a  graph.  A  naive 
definition  would  be  that  a  projected  execution  is  obtained  by  applying  II  to  each  state  in  the 
execution  sequence.  This  is  almost  the  appropriate  definition,  but  overlooks  the  situation  in 
which  consecutive  states  of  the  detailed  execution  project  to  the  same  state — a  possibility  we 
certainly  want  to  allow,  so  that  projections  can  reduce  the  number  of  steps  in  an  execution 
as  well  as  summarize  state. 

•  Let  (si)i  be  a  sequence  of  states.  We  define  II((s,)i)  to  be  the  sequence  (n(stj))j  where 
(ij)j  is  defined  by: 

i\  =  1  and  ij+\  =  the  smallest  i  >  ij  such  that  II(sj)  ^  II(s,-y) 

This  completes  the  set  of  definitions  we  need  for  the  following  result: 

Result  6  Let  G  be  a  transaction  graph,  and  11(G)  a  projection.  Then  II  projects  any 
execution  in  G  into  an  execution  in  11(G). 

Proof  Let  (s,);  be  an  execution  in  G,  and  (stj ) j  its  projection.  We  must  prove  that  for 
j  >  1,  n(siy)  is  a  subsequent  state  to  n(stj_,).  In  G,  we  know  that  S{}  is  a  subsequent  state 
to  that  the  state  change  was  localized  at  a  node,  and  caused  either  by  r  or  by  o.  Let 
su  be  the  state  of  u  at  Then  if  the  change  was  caused  by  r: 

nu(ru(su,<7u/aia(su/a)))  ^  7"n(o),o(Hu(^u))  nu/a,a(<^ru/a,o(^u/o))) 

=  7’n(a),a(Hu(,Su))  °’n(u/a),a(IIu/o,o(^u/o))) 


By  Tn(u),  we  of  course  mean  rnu(c/u),  where  du  is  the  activity  description  that  G  places  on 
node  u.  Thus,  Il(siy)  is  subsequent  to  II(s,-J_1).  The  case  for  o  is  similar. 

The  other  requirement  for  an  execution  is  that  the  values  along  an  arc  satisfy  the  protocol. 
This  is  true  for  the  sequence  of  states  seen  in  11(G)  because  it  holds  for  these  in  G,  and  by 
the  consistency  requirement  on  the  projections  of  values. 

□ 

The  point  is  that  whatever  can  be  ascertained  about  executions  in  the  view  can  be  understood 
as  a  result  about  the  detailed  execution.  Even  when  using  the  view  as  an  inspection  device, 
the  condition  that  it  is  a  projection  means  that  the  viewer  can  understand  what  is  and 
what  might  happen  next  in  a  self-contained  way — specifically,  in  terms  of  a,  r,  and  o  in  the 
projections. 
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2.5  Summary 

We  have  defined  a  graph-based  scheme  for  the  computat.jnal  tracking  and  modeling  of 
activity.  The  basic  building  block  is  an  activity  description ,  which  describes  “local”  activity. 
An  activity  description  governs  how  its  instances  can  be  connected  to  other  instances  of 
activity  descriptions  by  specifying  a  protocol  for  each  neighbor.  It  also  governs  the  evolution 
of  the  state  of  an  instance  of  the  activity  description:  the  parts  of  the  state  that  are  revealed 
to  neighbors,  the  rules  for  changing  that  part  of  a  state,  and  the  rule  for  changing  the  part 
of  the  state  not  seen  by  any  neighbor. 

Structurally,  a  transaction  graph  is  a  graph  whose  nodes  are  labeled  with  activity  de¬ 
scriptions.  Arcs  between  nodes  receive  two  protocols,  one  from  the  activity  description  on 
the  node  at  each  end.  There  is  a  conformance  rule  requiring  that  the  two  protocols  be  the 
same,  up  to  a  symmetry  operation.  Transaction  graphs  are  allowed  to  have  dangling  arcs, 
each  of  which  receives  only  one  protocol.  The  set  of  protocols  given  by  dangling  arcs  turns 
out  to  play  the  same  role  as  the  set  of  protocols  specified  by  an  activity  description. 

We  defined  the  notion  of  an  execution  of  transaction  graphs.  This  consists  of  execution 
steps  at  each  of  the  nodes,  governed  by  the  activity  description  on  a  node.  At  any  step,  a 
node  may  change  its  state  independently  of  its  neighbors,  or  it  may  transact  with  a  neighbor: 
it  may  change  its  state  in  a  way  that  depends  upon  its  state  and  the  part  of  the  neighbor’s 
state  made  visible  to  it.  (The  terminology  “transaction”  comes  from  the  fact  that  such  steps 
are  required  to  be  serializable:  adjacent  nodes  may  race  to  perform  a  transaction  along  an 
arc,  but  one  or  the  other  will  go  first.)  The  sequence  of  values  exposed  along  an  arc  must 
obey  the  protocol  on  the  arc. 

It  is  important  that  the  definition  of  execution  not  require  any  central  component  in 
an  implementation.  We  wish  to  support  applications  in  which  the  nodes  represent  loosely 
dependent  activities,  and  in  which  the  activities  may  be  proceeding  at  distant  sites.  Thus  the 
formalism  makes  quite  explicit  exactly  where  the  communication  happens  at  each  stage,  and 
it  requires  only  point-to-point  communication,  so  there  is  no  need  for  a  global  communication 
or  locking  mechanism. 

Much  of  the  discussion  here  has  been  toward  the  development  of  a  calculus  of  operations 
on  transaction  graphs.  The  first  part  of  this  discussion  showed  how  to  preserve  the  execution 
under  a  set  of  natural  graph-theoretic  transformations,  while  the  second  part  left  the  graph 
structure  invariant  and  showed  "how  to  characterize  summarization  of  execution. 

The  reader  may  be  concerned  that  transaction  graphs  as  a  formalism  do  not  provide 
an  immediate  basis  for  the  construction  of  activity  coordination  programs  by  novices.  In 
fact,  there  is  no  claim  to  the  contrary,  and  as  we  staled  at  the  outset,  our  goal  here  is  to 
provide  the  intellectual  basis  for  an  activity  coordination  system.  This  basis  must  meet 
other  criteria:  it  must  provide  a  coherent  “mentality”  for  an  eventual  system,  by  providing 
concepts  that  are  applicable  in  its  seemingly  disparate  parts.  In  chapter  3,  we  shall  see  how 
the  somewhat  theoretical  ideas  developed  here  relate  tu  real  world  aspects  of  an  activity 
coordination  system,  and  in  chapter  4  we  develop  several  higher  level  activity  descriptions 
and  operations  on  transaction  graphs. 
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3  Connections  to  Reality 

3.1  Parameterization  and  Instantiation 

One  never  specifies  an  activity  description  directly,  because  of  the  necessity  to  parameterize 
its  associated  functions  and  even  its  set  of  states.  We  thus  introduce  the  notion  of  a  param¬ 
eterized.  activity  description.  This  is  a  function  which,  when  applied  to  arguments,  yields  an 
activity  instantiation,  consisting  of  the  following  components. 

•  A  signature. 

•  A  list  of  functions  corresponding  to  cr,-. 

•  A  list  of  functions  corresponding  to  t,-. 

•  A  function  corresponding  to  o. 

•  A  state. 

For  example,  we  don’t  often  want  to  specify  an  activity  description  with  a  particular  person 
wired  in,  but  rather  a  parameterized  activity  description  which  can  be  invoked  with  a  person 
to  be  named  later.  Naturally,  the  parameterization  extends  to  transaction  graphs,  which  have 
the  additional  point  that  the  same  parameter  may  be  referenced  by  several  nodes. 

Recall  that  in  section  1  we  spoke  of  the  need  for  extensions  both  at  a  primitive  level  and 
at  a  graphical  level.  In  an  implementation,  there  would  be  a  way  to  write  parameterized 
activity  descriptions  in  whatever  language  was  aroropriate  (e.g.  C,  PASCAL,  or  Lisp); 
this  would  satisfy  the  need  to  extend  the  set  of  primitives.  An  implementation  would  also 
provide  a  means  for  constructing  parameterized  activity  descriptions  in  terms  of  its  graphical 
structure,  by  specifying: 

•  A  header  for  the  formal  parameters  of  the  activity  description  (not  to  be  confused 
with  the  names  on  dangling  arcs,  which  become  part  of  the  signature  of  the  activity 
description). 

•  A  graph  in  which  each  end  of  an  arc  is  labeled  with  a  name  (at  least  implicitly; 
conventions  can  be  used  to  reduce  the  number  of  names  that  must  actually  be  given 
directly). 

•  For  each  node  in  the  graph,  an  expression  which  will  evaluate  to  an  activity  instanti¬ 
ation  whose  signature  has  names  corresponding  to  the  nearby  names  oh  arcs  incident 
upon  this  node.  These  expressions  typically  involve  the  above-mentioned  formal  pa¬ 
rameters. 

When  an  activity  description  is  specified  in  this  way,  its  application  to  actual  parameters 
yields  an  activity  instantiation  whose  signature,  cr,  r,  o,  and  state  are  induced,  as  described 
in  section  2.3,  from  the  activity  instantiations  that  result  from  evaluating  the  expressions  on 
the  nodes.  This  provides  a  more  intuitive  level  at  which  to  construct  activity  descriptions. 
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We  have  thus  far  mentioned  two  extremes  in  specifying  parameterized  activity  descrip¬ 
tions:  the  primitive  level,  specified  entirely  in  a  standard  programming  language,  in  which 
the  resulting  activity  instantiation  has  no  internal  graphical  aspect,  and  the  “high”  level, 
specified  in  terms  of  a  static  graph,  and  thus  having  the  graphical  decomposition.  An  im¬ 
plementation  should  also  provide  for  hybrids  of  these  two  extremes:  it  would  be  useful  to 
be  able  to  write  parameterized  activity  descriptions  which  produced  activity  instantiations 
whose  graph  structure  depended  upon  the  parameters,  for  example,  the  number  of  arcs  leav¬ 
ing  a  node  might  depend  upon  the  size  of  a  set  parameter.  The  resulting  instantiation  would 
appear  to  a  user  as  if  it  were  executing  a  graph-based  activity  description,  rather  than  a 
primitive  activity  description.  Thus,  hybrid  parameterized  activity  descriptions  provide  a. 
powerful  means  of  encapsulating  regular  graph  structure,  even  if  it  is  not  statically  fixed  by 
a  parameterized  activity  description. 

3.2  Operations  on  Activity  Instantiations 

In  the  previous  section  we  defined  the  fundamental  means  of  constructing  an  activity  instan¬ 
tiation,  namely,  the  application  of  a  parameterized  activity  description  to  actual  parameters. 
In  this  section,  we  discuss  operations  on  these  objects.  The  most  obvious  are  to  set  one  in 
motion — to  begin  execution— and  to  view  the  current  state  of  the  state.  Indeed,  these  will 
probably  be  the  principal  operations  done  by  participants  in  coordinated  activities. 

Equally  important  to  implementers  and  extenders  of  the  system  are  implemented  versions 
of  some  of  the  operations  on  transaction  graphs  and  node  descriptions  discussed  in  chap¬ 
ter  2.  In  particular,  it  is  possible  to  obtain  activity  instantiations  not  only  by  their  ab  initio 
construction  using  parameterized  activity  descriptions  and  transaction  graphs,  but  also  by 
operations  that  have  activity  instantiations  as  arguments.  Corresponding  to  the  Results  of 
section  2.3  and  2.4,  the  following  are  candidates  for  implementation: 

•  pinching  two  vertices — takes  an  activity  instantiation  based  on  a  graph,  and  a  pair 
of  nodes  of  that  graph;,  yields  an  activity  instantiation  based  on  a  graph  obtained  as 
described  in  Result  1. 

•  shrinking  loops — similar  to  the  above,  but  based  on  Result  3. 

•  useful  combinations  of  the  above,  for  example  an  operation  that  takes  an  activity 
instantiation  based  on  a  graph  and  a  set  of  nodes  of  that  graph,  and  yields  an  activity 
instantiation  based  on  a  graph  obtained  by  pinching  all  the  nodes  in  that  set  and 
shrinking  all  the  loops  incident  upon  the  new  node. 

•  projection— lakes  an  activity  instantiation  and  a  rule  for  projecting  its  signature,  func¬ 
tions,  and  state;  yields  an  activity  instantiation  as  described  in  Result  6.  (If  the  given 
activity  instantiation  is  based  on  a  graph,  the  projection  rule  would  be  specified  node- 
by-node.) 

It  is  important  that  all  these  operations  be  done  in  such  a  way  that  the  original  instantiation 
and  the  resulting  instantiation  conceptually  share  the  same  state,  so  that  execution  of  one 
is  quite  directly  an  execution  of  the  other. 
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Another  essential  operation  on  activity  instantiations,  one  that  has  no  interesting  math¬ 
ematical  counterpart,  is  this: 

•  copy — takes  an  activity  instantiation  and  yields  a  distinct  activity  instantiation  with 
the  identical  state. 

This  lias  obvious  essential  roles  in  debugging  and  backup,  as  well  as  uses  discussed  in  later 
sections. 

While  there  is  no  claim  that  the  above  list  of  operations  on  activity  instantiations  is 
exhaustive,  and  while  we  would  certainly  consider  extending  it,  we  nevertheless  claim,  on 
the  basis  of  later  sections  of  this  chapter  and  of  chapter  4,  that  the  operations  have  wide 
application. 

3.3  User  Interface 

A  crucial  aspect  of  an  activity  coordination  system  is  its  user  interface.  In  this  section  we 
discover  that  the  program  that  deals  most  directly  with  the  user — displaying  the  state  of 
activity  instantiations  and  passing  directives  from  the  user  to  activity  instantiations — can 
literally  be  an  activity  description  in  the  process  of  executing.  Thus,  there  is  no  fundamental 
distinction  between  a  user’s  connection  to  the  system  and  the  way  that  the  system  works 
internally. 

We  will  begin  by  discussing  a  particular  projection  of  an  activity  instantiation  (as  dis¬ 
cussed  in  the  previous  section),  called  interface.  The  result  of  interface  is  an  activity  instan¬ 
tiation  whose  activity  description  has  a  degenerate  r  and  o — mathematically,  r(s,u)  =f  25 
and  o(s)  =f2s  for  every  s  and  v ,  i.e.,  from  the  point  of  view  of  r  and  o,  the  next  state  is 
completely  unspecified.  In  the  implementation,  the  meaning  of  this  is  that  all  the  changes 
to  the  state  arise  from  out-of-graph  communication. 

While  r  is  totally  useless  in  constraining  behavior,  it  is  quite  useful  in  other  respects.  To 
explain  how,  it  is  first  necessary  to  describe  the  state  of  the  projected  activity  instantiation. 
There  are  two  aspects  to  it: 

•  It  shares  state  with  the  argument  of  interface. 

•  It  contains  information  that  indicates  how  to  display  the  result. 

The  fact  that  the  result  of  interface  shares  state  with  the  argument  means  that  it  can  display 
it  on  the  user’s  screen.  The  additional  information  records  the  layout  of  nodes  (which  the 
user  may  change),  scrolling  position,  and  so  on. 

In  the  other  direction,  the  result  of  interface  also  is  aware  of  what  the  user  is  doing — 
typing,  mousing,  clicking — and  is  responsible  for  translating  these  into  the  form  of  out-of- 
graph  messages  expected  by  the  argument  to  interface. 

The  above  discussion  has  talked  about  an  inteiface  projection  as  if  there  would  be  only 
one.  Even  if  this  were  the  case,  there  is  an  advantage  to  implementing  it  as  a  projection, 
because  it  is  not  necessary  to  design  into  the  basic  machinery  any  “special  features”  which 
enable  communication  with  a  user.  A  larger  payoff  is  that  in  reality  there  will  be  several 
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interfaces.  For  example,  in  the  development  of  the  system,  we  will  probably  first  want  a 
simple  text  interface,  and  later,  a  more  graphical  one.  Another  example  is  an  interface  that 
would  tie  activity  instantiations  to  an  active  database.  Yet  another  example  is  considered 
in  the  next  section. 

3.4  History 

In  the  language  of  transaction  graphs,  a  history  is  equivalent  to  an  execution — it  is  simply 
a  sequence  of  states.  In  an  implementation,  a  history  is  obtained  by  interfacing  a  journal 
keeper  to  an  activity  instantiation.  In  other  words,  a  history  interface  responds  to  a  change 
not  by  updating  the  screen,  but  appending  an  entry  to  a  file. 

Not  just  any  entry  will  do,  of  course.  The  point  of  a  history  is  to  be  able  to  reconstruct 
an  execution,  which  constrains  the  nature  of  the  appended  entry.  The  natural  way  for  a 
user  to  view  history  is  with  exactly  the  same  machinery  used  to  view  the  original  execution, 
except  that  (a)  it  will  not  be  possible  to  affect  the  execution  (e.g.,  by  making  a  decision), 
and  (b),  it  will  be  possible  to  go  back  and  forth  in  time,  either  by  steps,  or  to  the  state  at  a 
particular  time.  This  specification  suggests  a  natural  implementation,  in  which  literally  the 
same  interface  is  set  up  with  a  state  that  is  shared  not  with  the  state  of  the  original  activity 
instantiation,  but  with  the  state  of  a  “history  viewer”,  itself  an  activity  instantiation.  The 
arguments  to  the  parameterized  activity  description  yielding  a  history  viewer  are  the  history 
interface  instantiation  and  the  journal  file.  It  begins  by  copying  the  state  and  noting  the 
corresponding  point  in  the  journal  file.  Its  execution  consists  of  listening  to  the  user  say 
things  like  “go  forward”,  “go  back”,  and  “go  to  time  x”;  the  changes  will  automatically 
appear  in  interfaces  referring  to  the  history  viewer. 

A  pragmatic  difficulty  in  dealing  with  history  is  how  much  of  it  to  keep.  It  is  fair  to  say 
that  this  is  not  a  system  problem,  because  it  is  ultimately  up  to  the  user,  but  it  is  also  true 
that  the  system  must  provide  facilities  that  allow  the  user  to  cope  with  the  problem.  The 
most  obvious  requirement  is  that  it  must  be  possible  to  cut  off  the  front  end  of  a  journal; 
events  that  happened  too  long  ago  (or  that  are  now  archived  off-line)  can  be  forgotten.  The 
more  interesting  issue  is  the  amount  of  detail  that  is  kept,  a  problem  already  mentioned  in 
connection  with  observing  an  ongoing  activity.  Naturally,  we  propose  the  same  means  to 
deal  with  it,  namely,  projection.  Thus,  while  a  history  is  always  a  recorded  execution,  that 
execution  may  not  be  the  lowest  level  execution,  but  rather  a  projection  of  it  that  removes 
extraneous  detail. 

The  fact  that  history  recording  and  viewing  are  implemented  as  activity  descriptions, 
and  the  use  of  projection  to  remove  detail,  makes  possible  useful  combinations  of  these 
techniques.  For  example,  one  might  record  quite  detailed  history,  which  is  kept  on  the  disk 
for  only  a  limited  period  of  time.  As  the  detailed  history  is  deleted,  (and  possibly  archived) 
it  can  be  projected  onto  a  less  detailed  history,  which  is  small  enough  to  keep  over  longer 
stretches.  Note  that  a  projection  may  be  designed  after  the  recording  of  detailed  history,  so 
if  at  some  later  phase  in  a  project,  one  wants  to  see  a  certain  projection  of  history,  one  goes 
to  the  archive  and  re-executes  the  history,  projecting  it  in  the  desired  way. 
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3.5  Implementation  of  <7,  r,  and  o 

In  the  formalization  of  activity  descriptions,  we  defined  r j  and  o  as  functions  that  yield  a  set 
of  possible  states,  and  an  execution  step  as  a  choice  from  the  union  of  the  results  of  r,  and 
o.  In  connecting  transaction  graphs  to  reality,  the  choice  must  be  resolved,  and  to  keep  the 
implementation  distributed,  it  is  natural  to  impose  the  responsibility  for  the  resolution  on  the 
implementation  of  an  activity  description.  Thus,  while  the  functions  r*  and  o  are  formally 
non-deterministic,  an  implementation  of  an  activity  description  is  deterministic — what  is 
non-deterministic  in  reality  is  the  order  in  which  events  occur.1 

An  activity  instantiation  may  need  to  persist  for  weeks  or  months,  and  as  we  have  em¬ 
phasized,  may  take  place  on  a  widely  distributed  network.  Thus,  while  we  tend  to  think  of 
an  activity  instantiation  as  an  execution,  it  cannot  conespond  literally  to,  for  example,  a 
Unix  process.  In  [KarS9]  we  developed  machinery  for  connecting  a  database  and  an  operat¬ 
ing  system  to  provide  a  facility  for  persistent  execution.  This  machinery  provides  a  natural 
basis  for  an  implementation  of  activity  descriptions,  as  we  now  briefly  outline. 

Let  us  assume  that  we  have  an  activity  instantiation,  based  on  a  graph,  and  that  all  of 
its  nodes  are  “asleep”,  i.e.,  stored  on  a  persistent  medium.  In  this  state,  the  activity  instan¬ 
tiation  is  waiting  for  an  out-of-graph  event,  such  as  the  passage  of  time  or  a  user  action. 
In  this  discussion  we  omit  the  details,  but  such  an  event  has  the  effect  of  “awakening”  a 
node  of  the  graph,  causing  the  execution  of  a  “transition  program”  [I<ar89].  The  implemen¬ 
tation  of  the  activity  description  for  the  awakened  node  is  in  its  transition  program.  The 
execution  of  the  activity  description  takes  whatever  action  is  appropriate,  including  perhaps 
transactions  with  other  nodes,  which  may  awaken  their  transition  programs  (perhaps  on 
distant  computers).  Eventually,  the  transition  program  for  the  awakened  node  completes  its 
set  of  actions,  and  puts  the  activity  instantiation  for  that  node  back  to  sleep.  Other  nodes, 
whether  awakened  by  the  node  first  awakened  or  by  independent  out-of-graph  events,  may 
still  be  awake,  and  go  on  executing  their  transition  programs  independently. 

This  brief  outline  necessarily  omits  many  issues  which  would  have  to  be  considered  in  a 
full-fledged  design  for  an  implementation,  but  there  are  several  points  that  are  natural  to 
raise  even  at  this  level  of  detail.  First,  we  note  that  while  the  theoretical  discussion  is  in  terms 
of  <r,  r,  and  o,  an  implementation  of  a  primitive  activity  description  is,  at  the  outer  level, 
a  dispatch  on  the  reason  for  which  it  is  being  awakened— some  kind  of  out-of-graph  event, 
or  because  of  a  transaction  initiated  by  a  neighbor.  Second,  whatever  the  reason  a  node 
is  awakened,  it  may  engage  in  transactions  with  its  neighbors,  when  it  does  so,  it  must  be 
prepared  to  cope  with  the  rejection  of  its  transaction,  and  allow  the  neighbor’s  transaction  to 
occur  first.  This  is  necessary  because  in  a  distributed  system  communication  takes  time,  and 
independent  nodes  may  “decide”  to  engage  in  a  transaction  without  knowing,  until  it  is  too 
late,  that  they  are  in  a  race.  Third,  when  an  activity  instantiation  for  a  node  u  is  asleep,  then 
ru(su, uu/a,a)  =  0  for  all  arcs  incident  upon  u.  If  in  addition  o(su)  —  0,  the  vertex  is  said 
to  be  stable — it  can  be  changed  only  by  transactions.  Thus,  if  the  activity  instantiations 
for  all  the  nodes  of  the  graph  are  stable,  the  termination  condition  of  section  2.2  is  met. 
This  suggests  that  each  activity  instantiation  record  whether  o(su)  =  0,  thereby  enabling 

'This  is  a  slight  over  simplification  we  would  not  wish  to  preclude  the  use  of  deliberately  randomized 
algorithms  in  activity  descriptions. 
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detection  of  termination. 

Finally,  there  is  the  necessity  to  provide  for  shared  state,  as  we  discussed  in  previous 
sections.  In  a  distributed  system,  it  is  not  feasible  to  do  this  literally.  However,  the  desired 
effect  can  be  achieved  by  establishing  the  convention  that  implementation  of  an  activity 
description  announce  changes  to  its  state.  Activity  instantiations  that  view  other  activity 
instantiations  arrange  to  receive  out-of-graph  events  when  such  changes  occur,  and  are  thus 
able  to  track  the  progress  of  viewed  activity  instantiations.  (We  have  used  this  technique 
successfully  in  the  implementation  of  the  E-L  system.) 

In  summary,  the  implementation  of  primitive  activity  descriptions,  in  so  far  as  their 
incorporation  into  the  activity  coordination  system  is  concerned,  is  a  well-structured  task. 
These  functions  must: 

•  respond  to  possible  events,  including  transactions  of  neighbors  and  out-of-graph  events; 

•  when  necessary,  engage  in  transactions  with  neighbors,  which  may  possibly  be  rejected; 

»  announce  changes  of  state;  and 

•  indicate  whether  the  activity  instantiation  is  stable. 

We  anticipate  no  great  difficulties  in  filling  out  the  design  and  doing  the  implementation. 

3.6  Cutover 

In  section  1,  we  mentioned  the  “cutover”  problem:  how  to  change  descriptions  of  activities 
while  the  activities  themselves  are  under  way.  We  are  now  in  a  position  to  pose  the  problem 
in  a  more  formal  way:  how  do  we  modify  an  activity  instantiation  whose  execution  is  under 
way?  We  can  further  set  forth  a  criterion  for  the  form  a  solution  should  take: 

•  If  both  the  old  and  new  activity  descriptions  are  specified  as  transaction  graphs,  we 
would  like  to  express  the  cutover  technique  at  the  level  of  transaction  graphs. 

Recall  that  execution  is  defined  for  only  those  activity  descriptions  with  no  dangling 
arcs,  i.e.,  with  an  empty  signature  (section  2.2).  Let  us  consider  an  activity  description  d, 
with  no  internal  graph  structure,  or  at  least  where  the  graph  structure  has  been  removed  by 
condensation  to  a  single  node,  as  described  in  section  2.3,  so  that  the  only  function  to  worry 
about  is  o  :  Sd  — >  25d.  The  most  general  definition  of  a  cutover  is  a  map  that  takes  o,s  to 
o',  s',  the  idea  being  that  execution  continues  using  o'  on  s'.  There  are  two  problems  with 
this  definition.  First,  even  given  the  description  of  the  map,  what  are  the  engineering  issues 
in  actually  effecting  the  cutover  of  an  activity  instantiation?  Second,  the  definition  is  so 
general  that  it  is  useless — it  provides  no  insight  into  how  to  obtain  o'  and  s'  in  a  reasonable 
way. 

We  consider  first  the  engineering  issue.  The  restrictions  we  have  already  imposed  on 
activity  instantiations  make  this  problem  less  terrifyingly  impossible  than  it  might  first 
appear.  In  particular,  the  fact  that  the  state  of  an  execution  can  be  written  to  disk  and 
restored  to  fast  memory  means  that  there  is  a  well- specified  clean  point  at  which  cutover 
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can  occur.  In  implementation  terms,  all  that  is  necessary  is  to  ensure  that  the  activity 
instantiation  is  in  persistent  storage  (rather  than  fast  memory),  and  then  to  change  the 
transition  program  and  state  associated  with  with  it.  All  of  the  many  issues  that  would  arise 
in  cutting  over  an  executing  UNIX  process  simply  don’t  arise. 

We  now  turn  to  the  issue  of  producing  o'  and  s'.  The  easy  part  is  producing  a  new 
o':  this  corresponds  to  changing  the  program,  an  activity  with  which  we  are  all  familiar. 
As  a  simple  first  case,  then,  we  characterize  the  situation  in  which  s  =  s'  (but  o  ^  o')  as 
state-invariant  cutover.  In  addition  to  being  used  in  the  obvious  way,  to  indicate  that  from 
now  on,  things  will  be  done  differently,  state- invariant  cutover  may  be  used  to  recover  from 
states  that  are  erroneous  because  of  bugs  in  an  activity  description.  Recall  that  the  history 
viewer  literally  operates  on  a  states.  The  technique  is  to  back  up  in  time  until  a  satisfactory 
state  is  reached,  and  then  to  resume  execution  with  the  new  activity  description  (o')  and  the 
desired  state  (s').  (This  technique  assumes  that  history  is  recorded  at  the  level  of  detailed 
execution,  making  that  a  wise  thing  to  do  during  debugging.) 

We  now  drop  the  assumption  that  the  interesting  graph  structure  in  an  activity  descrip¬ 
tion  has  been  condensed  out,  and  propose  an  approach  to  cutover  that  exploits  the  fact 
that  activity  descriptions  often  arise  as  transaction  graphs,  composed  by  connecting  simpler 
activity  descriptions  having  non-empty  signatures.  The  basic  idea  is  to  support  cutover  at 
a  vertex  of  a  transaction  graph  leaving  the  state  and  activity  description  at  all  other  nodes 
unchanged. 

One  might  claim  that  in  general  it  is  not  enough  to  be  able,  to  change  a  single  node;  it 
might  be  necessary  to  restructure  an  entire  subgraph.  Indeed  this  is  the  case,  but  doing  so 
actually  involves  three  steps. 

1.  Restructure  the  graph  by  condensing  and  uncondensing  subgraphs  to  isolate  the  change 
at  a  single  node. 

2.  EfFect  a  cutover  at  the  node. 

3.  Restructure  the  graph  to  correspond  to  the  desired  structure  of  the  revised  activity 
description. 

The  restructuring  of  a  graph  is  one  that  produces  a  new  a',  t\  o'  and  s'  jointly,  but  in  a 
way  which  is  very  stylized  and  preserves  the  essential  semantics  of  the  program.  As  indi¬ 
cated,  the  new  functions  are  produced  from  the  old  by  graph  operations.  From  section  2.3, 
it  is  evident  that  s'  differs  from  s  by  transformations  of  the  form  (...  ($i,..  .,$*).. .)  <-> 
(. . . ,  Si, . . . , Sk . . .),  i.e.,  just  by  grouping  operations  on  tuples.  The  operations  on  tuples  can 
be  carried  out  automatically,  given  the  transformations  that  take  r  to  r'. 

There  remains  the  problem:  how  does  a  person  conveniently  create  a  new  state?  The 
answer  is,  the  same  was  as  always,  by  executing  an  activity  description.  To  be  more  explicit, 
suppose  that  in  graph  G ,  there  is  a  node  u  which  we  wish  to  cut  over  to  a  new  cr'u,T^,o'u, 
and  Sy.  Then,  in  general,  we  construct  a  G1  with  vertex  u'  whose  activity  description  has 
the  same  signature  as  that  on  u,  with  ov,tu/,  and  ou>  being  the  desired  <?■(,,  r',  and  o'u.  We 
then  execute  G'  to  produce  the  desired  s'u  as  the  state  at  u'.  The  final  step  in  the  cutover  is 
to  say  that  node  u  in  the  activity  instantiation  based  on  G  is  to  be  cut  over  to  node  u'  in  the 
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instantiation  based  on  G'.  This,  like  state-invariant  cutover  and  graph-restructuring,  can  be 
done  in  generic  way.  We  should  note  that  it  also  has  the  effect  of  deleting  the  state  at  u  in 
the  execution  of  G,  and  at  all  nodes  in  the  execution  of  G'  other  than  it'.  (An  interesting 
variation  is  to  continue  the  execution  G',  but  for  its  state  at  u'  to  become  the  state  that 
was  at  u,  in  other  words,  for  G  and  G'  to  exchange  states  between  u  and  u'.  Admittedly,  no 
application  springs  immediately  to  mind.) 

There  is  no  claim  here  that  this  trivializes  the  problem  of  cutover.  This  design  does, 
however,  satisfy  the  criterion  that  cutover  be  accomplished  at  the  same  level  as  the  changes  to 
activity  descriptions.  In  particular,  a  person  who  is  working  solely  at  the  level  of  transaction 
graphs  (i.e.,  not  introducing  primitive  transaction  protocols)  can  effect  cutover  solely  in 
terms  of  transaction  graphs. 
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4  Some  Common  Idioms 

The  transaction  graph  formalism  was  deliberately  designed  to  favor  formal  simplicity  and 
composability  over  the  inclusion  of  many  “features”  at  a  fundamental  level.  The  rationale  is 
that  if  the  basic  design  is  clean  and  powerful,  the  desired  features  can  be  programmed  and 
encapsulated.  In  the  sections  below,  we  consider  common  patterns  of  graph  manipulation 
that  can  be  done  using  the  fundamental  operations  described  in  section  2.3,  and  we  provide 
several  paradigmatic  activity  descriptions.  The  aim  here  is  not  to  be  complete,  but  to 
demonstrate  that  a  high-level  system  can  indeed  be  build  on  this  foundation. 

4.1  Deleting  Arcs  and  Nodes 

The  basic  graph  operations  previously  discussed  provide  the  ability  to  unconditionally  trans¬ 
form  graph  structure,  yet  to  retain  the  semantics  of  execution.  It  is  clearly  not  possible  to 
unconditionally  delete  an  arc  or  node  and  retain  execution  semantics,  but  there  is  an  obvious 
condition  under  which  this  is  possible.  For  arcs,  a  sufficient  condition  is  that  activity  de¬ 
scriptions  on  the  nodes  at  each  end  of  the  arc  behave  independently  of  the  value  seen  along 
the  arc.  To  be  more  precise,  we  say  that  d  ignores  arc  io  <&f  is  independent  of  its  second 
argument,  i.e.,  there  is  a  function  0d  :  Sd  — >  2Sd  such  that: 

•  Tdtio(s,v)  =  Od(s),  for  all  s  €  Sd. 

The  fundamental  transformation  is  on  activity  descriptions: 


Let  the  activity  description  on  the  left  be  d  with  signature  (n,  :  p% ),  and  assume  d  ignores 
io',  for  convenience,  that  on  the  right  will  be  d'  with  signature  (n,  :  Pi)x?i0  and  functions: 

•  < 7d>,i  and  Td',i  are  the  same  as  ad,i  and  respectively,  for  i  ^  io. 

•  od'(s )  =  od{s)  U  0'(s) 

Suppose  that  a  graph  has  nodes  ui  and  u2  joined  by  an  arc  a 0,  and  that  each  of  u\  and  u2  has 
an  activity  description  that  ignores  «o.  The  operations  to  delete  the  arc  may  be  expressed 
as  follows: 

•  Pinch  the  nodes  at  each  end  of  the  arc,  and  shrink  a0  (now  a  loop),  obtaining  the 
following  functions  for  now  node  u0: 

-  o'o,a(('Si,52))  for  a  ^  ao  carries  over  from  crI>a(s,),  where  a  was  incident  upon  u 

-  Similarly  for  r0,a((si,S2),u). 
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-  o((Si,S2))  =  Oi(Si)U  02(52)  Uri>ao(5i,(T2,a0(52))Ur2,ao(52,Cri,ao(si)) 

=  Oi(5l)Uf?i(51)Uo2(S2)U02(52) 

The  first  equality  comes  from  shrinking  ao,t  and  the  second,  from  the  assumption  that 
Ui  ignores  a0,  for  i  =  1  and  2. 

•  Unpinch  u0  to  obtain  u[  and  u2  with  activity  descriptions  d',  j  =  1  and  2,  where: 

_  tf'd'-.a  and  Td'.ia  for  a  ^  a0  are  the  same  as  ad}<a  and  t^.q,  respectively. 

-  od'(s)  =  odj(s)  U  0d}(s) 

Thus  u'j  has  the  above-described  transformation  of  dj. 

The  results  for  pinching  and  shrinking  guarantee  that  the  graph  with  the  deleted  arc  has 
executions  in  1-1  correspondence  with  the  original  graph. 

Why  would  anyone  write  a  transaction  graph  with  a  deletable  arc?  One  probably  would 
not,  at  least  not  directly.  The  real  utility  of  this  transformation  is  in  its  combination  with 
projection — even  though  an  activity  description  does  not  ignore  z’o,  a  projection  might.  Thus 
projection  not  only  simplifies  states  and  shortens  execution  sequences,  it  can  also  be  viewed 
as  simplifying  the  pattern  of  coordination.  This  is  a  formal  property  that  corresponds  to 
real-world  experience:  at  a  gross  level,  certain  activities  may  be  described  as  independent, 
while  if  one  takes  a  closer  look,  it  becomes  clear  that  dependencies  do  exist. 

For  deleting  a  node,  the  condition  is  that  its  activity  description  has  the  following  prop¬ 
erty: 

d  is  boring  its  signature  is  empty  and  od(s)  =  0  for  all  s. 

Let  a  node  Ui  have  a  boring  activity  description.  Then  ux  can  be  deleted  as  follows: 

•  Pinch  u\  together  with  any  other  node  u2,  obtaining  the  following  functions: 

-  Vd0({s\,s2))  =  crd2ii(s2) 

-  rrfo((si,s2))  =  {si}  x  Td2ii(s2yv) 

-  Odo((sus2))  =  od,(si)  X  {s2}  U  {si}  X  odi(s2)  =  {si}  X  odi(s2) 

The  first  two  items  use  the  fact  that  U\  has  no  incident  arcs,  and  the  last,  the  fact  that 
Od,(s)  =  0. 

•  Because  d\  enters  into  no  transaction  that  would  change  its  state,  and  because  odl  (s)  = 
0,  the  initial  state  of  U\  remains  forever  unchanged,  i.e.,  si  in  the  above  equations  is 
a  constant.  Thus  there  is  a  1-1  correspondence  of  states  between  u2  and  uo,  given  by 
S2  <->  (si,s2).  Hence,  we  can  map  the  state  on  u0  back  to  what  it  would  have  been 
on  u2:  and  revert  to  the  original  crdj.Td 2,  and  0^,  and  have  a  1-1  correspondence  in 
execution. 

In  effect,  no  trace  of  u\  remains.  Of  course,  an  implementation  would  delete  ui  directly,  and 
not  literally  go  through  the  steps  that  justify  doing  so. 

As  with  ignoring  an  arc,  one  is  not  going  to  write  boring  activity  descriptions  on  purpose; 
their  utility  arises  in  connection  with  projection  and  other  transformations.  In  the  next 
section  we  give  an  example  that  combines  projection  and  deletion  of  both  arcs  and  nodes. 
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4.2  Subgraph  Extraction 

The  goal  of  this  section  is  to  “understand”  a  subgraph  Go  of  a  given  graph  G  on  its  own 
terms,  where  by  “on  its  own  terms”  we  mean  that  we  wish  to  leave  Go  itself  untouched, 
and  to  view  transactions  along  arcs  leaving  it  as  contributing  to  the  non-determinacy  of 
execution  in  the  subgraph.  More  formally,  our  strategy  is  to  define  a  projection  on  G  which 
is  the  identity  on  nodes  in  Go.  The  question  then  is,  what  happens  to  nodes  outside  Go? 
We  first  consider  the  special  case  in  which  such  a  node  has  only  one  arc,  the  other  end  of 
which  touches  a  node  in  Go,  and  has  (n  :  p)  as  the  signature  for  its  activity  description. 
In  order  to  make  the  projection  independent  of  the  graph  outside  Go,  what  we  need  is  the 
universal  activity  description  for  protocol  p  with  name  n,  denoted  dp<n.  The  definition  is  a 
bit  technical,  but  the  idea  is  simple:  dPiTl  always  responds  to  a  sequence  of  transactions  in  a 
legal  way,  but  is  unpredictable  up  to  the  constraints  imposed  by  p.  The  easy  part  is  this: 


•  The  signature  for  dPi„  is  (n  :  p). 

•  The  other  constituents  depend  only  upon  p,  and  will  be  denoted  Sp,  crp,  rp,  and  op 


•  op(s )  =f  0  for  all  s  €  Sp. 


The  technicalities  for  the  definitions  of  <Sp,crp,  and  rp  are  in  Appendix  A,  where  it  is  shown 
that  there  is  a  projection  from  d  to  dp>n. 

Generalizing  the  situation,  suppose  that  a  node  u  not  in  Go  has  activity  description  d 
with  signature  ( n ,  :  p,),.  By  “i  touches  Go”,  we  mean  that  the  other  end  of  the  arc  whose 
u-relative  name  is  nt  touches  a  node  in  Go-  The  projection  for  u  takes  d  to  an  activity 
description  that  behaves  on  arc  i  like  the  universal  activity  description  for  p,  if  i  touches  Go, 
and  which  otherwise  ignores  arc  i.  Formally: 


n((nt- :  Pi)i)  =  ( n{ : 


Pi 

true 


if  i  touches  Go 
otherwise 


r.  dcf  \y  0 

•  <->n(<q  =  *  oj, 

i  touches  Go 


nK')((ii)i  touches  Go  5^)  ~ 
n(r(i,; ) ( (Sj)j  touches  Go  >  == 


/  aPiisi)  ^  i  touches  Go 
\  0  (or  any  other  arbitrary  fixed 

'  /  rPi(si,v)  \ij=i  \ 

<  j  touchcsGo  |  s.  otherwise/ 

.  0 


value)  otherwise 

if  i  touches  Go 
otherwise 


•  n(orf)((sJb  touches  Go)  =f  0 

We  omit  the  proof  that  there  is  a  projection  from  d  to  the  activity  description  with  these 
components. 

Now  let  us  examine  the  result  of  this  projection.  We  first  observe  that  an  arc  between 
two  nodes  not  in  Go  is  ignored  by  both  nodes,  and  hence  may  be  deleted,  by  the  previous 
section.  After  deleting  all  the  arcs,  any  nodes  that  are  not  adjacent  to  a  node  in  Go  will  be 
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Pi  if  i  touches  Go 
true  otherwise 


dcf  v'  o 

<->n(d)  =  A  <• >d , 

i  touches  Go 


rr,  \ / /  \  \  dcf  f  crpi(s{)  if  i  touches  G0 

nKiXteh  io«ci...c.,»)  =  ( 0”  .  other  s 


(or  any  other  arbitrary  fixed  value)  otherwise 


n(r*f)( Mi  Md,c,a0,v)  {  X->  {  s' 

i  0 


Tp,(SnU)  if  j=i 
Si  otherwise 


if  i  touches  Go 
otherwise 


•  n(Od)((Sjb  touches  Go)  =  0 
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components. 
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boring,  and  thus  may  be  deleted,  again  by  the  previous  section.  Finally,  any  remaining  node 
not  in  Go  will  have  arcs  to  one  or  more  nodes  in  Go.  If  the  number  of  arcs  is  greater  than 
1,  it  may  be  unpinched2  until  all  nodes  not  in  Go  have  a  single  arc  that  touches  a  node  in 
Go .  This  is  the  last  step  of  the  construction — we  now  have  a  graph  that  embeds  Go  but  is 
completely  independent  of  the  graph  structure  of  G  not  in  Go- 

The  purpose  of  pursuing  this  is  example  is  to  offer  evidence  of  the  power  of  the  pinching, 
shrinking  and  projection  operations.  Starting  with  an  informal  notion  of  wanting  to  “under¬ 
stand”  a  subgraph  of  a  graph,  the  exercise  of  formalizing  this  in  terms  of  the  operations  of 
section  2.3  and  2.4  leads  inevitably  to  the  necessity  of  constructing  an  activity  description 
that  behaves  as  the  most  general  participant  in  a  protocol,  which  we  called  the  universal 
activity  description  for  a  protocol.  If  we  want  merely  to  look  at  a  subgraph  of  a  graph,  it 
would  be  overkill  to  invoke  all  this  machinery.  However,  if  we  want  to  simulate  or  analyze  a 
subgraph,  or  if  we  want  to  test  and  debug  an  activity  protocol  with  a  non-empty  signature, 
an  implemented  version  of  dPiH  is  exactly  what  we  need.  So  the  seemingly  technical  device 
that  we  used  to  formalize  extracting  a  subgraph  from  a  graph  turns  out  to  have  important 
connections  to  reality. 


4.3  Collapsing  Parallel  Arcs 

Section  2.3  showed  how  to  condense  any  subgraph  of  a  graph  to  a  single  node  u0  without 
loops.  Consider  a  node  uj  outside  the  subgraph,  which  in  the  original  graph  had  arcs 
to  distinct  nodes  in  the  subgraph.  In  the  transformed  graph,  the  nodes  u0  and  ui  will  be 
connected  by  several  arcs.  Arcs  that  are  incident  on  the  same  pair  of  nodes  are  called  parallel ; 
the  purpose  of  this  section  is  to  describe  how  parallel  arcs  can  be  collapsed  to  a  single  arc, 
and  the  activity  descriptions  on  the  nodes  adjusted  so  that  there  is  still  a  1-1  correspondence 
in  executions.  The  essence  of  the  transformation  is  on  an  activity  description: 


The  heavy  arc  on  the  right  is  obtained  by  collapsing  the  two  arcs  near  each  other  on  the  left. 
Let  the  activity  description  on  the  left  be  d  with  signature  ( n ,  :  pt)t.  For  convenience,  let  n0 
be  the  name  for  the  heavy  arc.  (Choose  no  ^  n,,i  >  2.)  The  signature  for  the  new  activity 
description  d'  will  be  (no  :  po>  ^3  :  P3,  -  -  - ,  n*  :  pjt),  where  we  have  no  vet  defined  po.  Before 
doing  so,  we  note  that  d'  inherits  the  set  of  states  from  d ,  the  definitions  of  a ^  and  r^,  for 
i  >  2,  and  the  definition  of  Od- 

The  idea  is  that  a  value  seen  along  the  collapsed  arc  consists  of  the  pair  of  values  seen 
along  the  two  uncollapsed  arcs.  There  are  two  technical  assumptions  that  we  must  make: 
the  first  is  that  V  x  V  C  V,  i.e.,  if  Vi,v2  €  V ,  then  (vi,v2)  €  V.  The  second  has  to  do 

2The  pinching  and  shrinking  transformations  are  equivalences,  and  may  be  applied  in  either  direction,  by 
“un-”,  we  mean  in  the  direction  opposite  to  the  one  stated. 
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with  a  corresponding  operation  on  protocols.  Given  pi,p2  €  P,  we  assume  that  there  is  a 
Pi  x  P2  €  P  with  the  following  action  as  a  predicate: 

•  (Pi  x  P2)(({fiivi))i)  ^  every  u;  can  be  written  in  the  form  (v,i,u.-2)>  and  ) 

holds  for  j  =  1  and  2. 

We  note  that  (pi  x  p2)T  =  pf  x  p^,  i.e.,  they  have  the  same  action  as  predicates. 

Naturally,  we  let  po  =f  pi  x  p2,  thus  completing  the  signature  for  d',  and  to  complete  the 
definition  of  the  entire  activity  description: 

•  <7d',o(s)  =  (crd,i(s),adi2(s)) 

•  Td>fi(s,(vUV2))  =  Td>i($,Vl){jTd,'i(s,V2) 

•  Odi(s)  =f  od(s) 

Result  7  Let  and  u2  be  nodes  in  a  graph  with  activity  descriptions  d\  and  d2,  and 
suppose  that  a\  and  a2  are  parallel  arcs  adjoining  them;  for  convenience,  assume  that  a,  is 
the  ith  arc  on  each  node.  Obtain  a  new  graph  by  collapsing  ai  and  a2  to  a  single  arc  a0, 
and  by  replacing  the  activity  description  on  u,  by  d',  as  outlined  above.  Then  there  is  a  1-1 
correspondence  between  the  execution  of  the  two  graphs. 

Proof  We  can  view  this  as  a  sequence  of  elementary  transformations: 

•  Pinch  ui  and  u2,  then  shrink  cn  and  a2,  now  loops,  obtaining  the  following  functions 
for  the  new  node  u0. 


-  ^o,a((-Si,52))  for  a  ^  ai,G2  carries  over  from  cri,a(s). 

-  Similarly  for  r0, a((5i,s2),u). 

-  o0((si,s2))  =  O^Sj)  x  {s2}  U  {sx}  x  o2(s2) 

U  rliai(si,<72)aj(s2))  X  {s2}  U  {si}  X  T2l0l(s2,(7l1a1(5l)) 
u  Tl,a2(si,<72,a2(s2))  X  {s2}  U  {sX}  X  T2)02  (s2,  <T1)02(si )) 
=  Ol(-Sl)  X  {s2}  U  {Sj}  X  o2(s2) 
u  Tdi0(si,ad,,ao((sus2)))  x  {s2} 

U  {sj}  x  Tdl>ao(s2,adl<ao({sl:s2))) 

•  Unshrink  a  new  arc  Go  and  then  unpinch  to  get  nodes  u\,u'2  with: 

t  \  _  /  aiAsi)  if  a^G1,a2 
kA' 1,-\  tf«=OC 

-  Similarly  for  ru'ia 

-  =  o(si) 
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The  protocol  p\  x  p2  has  clearly  been  constructed  to  be  valid  for  the  communication  on  a0. 
□ 

Thus,  parallel  arcs  can  always  be  collapsed,  assuming  that  V  x  V'  C  V  and  that  P  is  closed 
under  the  product  operations  discussed  above. 

We  state  without  proof  several  relationships  that  collapsing  arcs  has  with  other  opera¬ 
tions.  First,  shrinking  and  collapsing  commute: 

Result  8  Let  he  distinct  indices  of  the  signature  of  activity  description  d,  and 

form  d'  by  collapsing  i\  and  (2,  and  i\  and  z'2,  calling  the  result  indices  io  and  i'0.  Then: 

d~  =d'  -  [Wo] 


□ 

Result  9  Let  h,i2,  and  23  be  distinct  indices  of  the  signature  of  activity  description  d,  form 
d(i,2),3  by  collapsing  ii  and  *2,  and  the  resulting  dangling  arc  with  i$,  and  form  <^(2,3)  by 
collapsing  and  23,  and  then  collapsing  i\  with  the  resulting  dangling  arc.  Then: 

d<l,2),3  =  ^1,(2, 3) 


□ 

At  the  beginning  of  this  section,  we  remarked  that  collapsing  parallel  arcs  is  useful  in  tidying 
up  a  graph  which  has  had  a  subgraph  condensed  to  a  node.  In  an  implementation  this 
might  be  done  automatically.  In  the  next  section,  we  shall  see  another  use  for  this  graph 
transformation. 

4.4  Products  of  Isomorphic  Graphs 

A  common  pattern  of  activity  is  the  assignment  of  essentially  the  same  task  to  several  persons, 
for  example,  all  members  of  a  committee  are  to  receive  a  report  and  submit  a  review  by  a 
certain  date.  It  is  quite  natural  to  describe  what  a  committee  member  does  from  the  point 
of  view  of  one  member,  but  from  the  point  of  view  of  the  person  who  assigns  the  task  to  the 
committee  and  who  collects  the  reviews,  it  is  natural  to  look  at  one  graph  that  summarizes 
the  behavior  of  all  the  members  of  the  committee. 

The  notion  of  projected  execution  (section  2.4)  supplies  precisely  the  right  technique  for 
obtaining  from  the  single  graph,  the  view  that  is  specific  to  a  particular  committee  member. 
What  is  needed  is  a  way  to  obtain  the  single  transaction  graph  that  captures  the  behavior 
of  a  set  of  participants  from  a  graph  that  specifies  the  behavior  of  a  single  participant,  and 
does  so  in  such  a  way  that  it  is  possible  project  the  appropriate  view  for  each  particular 
participant. 

As  the  title  of  this  section  suggests,  we  will  formalize  the  notion  of  “essentially  the  same 
task”  to  mean  that  the  activity  descriptions  are  based  on  isomorphic  graphs.  We  do  not 
require  that  the  activity  descriptions  on  corresponding  nodes  be  in  any  way  related,  but  we 
will  assume  that  arcs  which  are  paired  by  the  isomorphism  have  the  same  names — this  is 
not  a  real  restriction,  since  renaming  is  always  possible.  The  details: 
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•  Let  G\  and  G2  be  isomorphic  transaction  graphs.  This  product,  denoted  G\  x  G2,  is 
constructed  as  follows: 

-  Pinch  each  pair  of  xiodes  that  is  paired  by  the  isomorphism. 

-  For  each  pair  of  dangling  arcs  paired  by  the  isomorphism,  transform  the  activity 
description  on  the  node  as  described  in  section  4.3. 

-  For  each  pair  of  non-dangling  arcs  paired  by  the  isomorphism,  collapse  the  arcs 
as  described  later  on  in  the  same  section. 

-  Let  the  signature  of  G;  be  (rij  :  Pij)y,  the  signature  of  G 1  x  G2  is  evidently  given 
by  (nj  :  py  x  p2j)j. 

We  state  without  proof  several  desirable  properties  of  this  construction.  The  first  says  that 
the  product  is  associative  and  commutative,  so  that  we  can  write  Gt\  x  G2  x  Gz  without 
ambiguity,  and  similarly  X<g/G,,  where  1  is  an  index  set.  Further,  there  is  an  identity 
element,  so  the  latter  makes  sense  even  if  I  =  0. 

Result  10  Let  G\,G2,Gz  all  have  isomorphic  graph  structure.  Define  1©  to  have  the  same 
graph  structure,  where  the  protocol  on  a  vertex  is  the  boring  protocol  with  the  appropriate 
signature.  Then: 


G\  x  G2  =  G2  x  Gi  Gi  x  (G2  x  Gz)  —  (Gi  x  G2)  x  Gz  G,-  x  1g  =  G,- 

□ 

Product  and  projection  work  in  the  way  one  expects: 

Result  11  Let  Gi,G2  be  transaction  graphs  such  that  G\  x  G2  is  defined.  Let: 

•  IT  fa  :  pij  x  p2j)j  =  ( nj  :  py)f 

•  Ui(di  x  d2)  =  di 

•  Ui((si,s2))d=  Si 

•  n,-((ui,u2))  =fu,- 

Then  n,(Gi  x  G2)  =  G,-,  for  i  =  1  and  2. 

□ 

Finally,  there  is  a  natural  connection  between  graphical  collapse  and  products  of  protocols 
and  graphs. 

Result  12  Lei  G'i,G2  be  as  above,  and  foi  an>  G,  let  da  be  the  transaction  protocol  obtained 
by  collapsing  G  to  a  single  vertex.  Then: 

d>Gi  xG?  =  dat  x 


□ 
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4.5  Exclusive  Access 

Because  of  the  strong  desire  to  achieve  a  distributed  system,  transaction  graphs  have  been 
defined  to  be  quite  asynchronous — each  node  talks  to  only  one  neighbor  at  a  time,  and  there 
is  no  central  overseer  of  the  communication.  And  even  this  communication  does  not  require 
the  active  participation  of  the  neighbor — in  fact  the  main  restriction  on  this  communication 
is  that  the  neighbor  not  be  too  active,  i.e.,  trying  to  communicate  at  the  same  time. 

While  the  implementation  basis  for  an  activity  coordination  system  is  necessarily  dis¬ 
tributed  and  thus  provides  only  loose  coupling  among  the  constituents,  it  is  also  the  case 
that  a  rather  fundamental  form  of  activity  “coordination”  requires  tighter  coupling,  namely, 
exclusive  access — ensuring  that  among  a  subset  of  competitors  wanting  access  to  a  resource, 
permission  will  be  granted  to  only  one  at  a  time.  In  a  distributed  system,  we  can  expect 
that  non-adjacent  nodes  may  concurrently  arrive  at  a  state  in  which  they  need  exclusive 
access  to  a  resource,  but  of  course,  a  node  cannot  unilaterally  decide  that  it  has  such  access. 
There  may  be  several  ways  to  pose  the  problem  in  a  formal  way;  the  one  we  choose  is  based 
on  a  classical  two-phase  notion:  a  node  announces  that  it  would  like  exclusive  access;  some 
communication  ensues,  which  results  in  the  node’s  being  told  that  all  other  nodes  agree  that 
it  can  have  exclusive  access,  or  not.  If  exclusive  access  is  denied,  the  node  may  re-try,  but 
it  may  also  decide,  on  the  basis  of  the  new  information  it  received  that  it  is  no  longer  inter¬ 
ested  in  exclusive  access.  This  section  will  provide  one  formalization  of  what  exclusive  access 
might  mean,  and  will  provide  one  implementation  which  gives  rise  to  the  desired  behavior. 
There  are  no  doubt  both  other  definitions  of  exclusive  access  and  other  implementations  that 
would  meet  the  definition  we  have  chosen,  so  the  goal  here  is  not  to  provide  the  ultimate 
technique  for  exclusive  access,  but  rather  to  give  an  example  of  the  use  of  transaction  graphs, 
admittedly  at  a  rather  low  level,  for  a  very  real  and  practical  problem. 

For  simplicity,  we  will  assume  that  all  the  nodes  of  the  graph  are  potent- a!  competitors. 
In  practice,  this  would  more  likely  be  a  subset  of  nodes;  the  subset  might  even  be  dynamically 
determined.  The  definition  will  use  the  idea  that  a  node  goes  through  phases.  Each  node 
starts  at  phase  0,  and  the  phases  are  numbered  sequentially.  (The  phase  does  not  have  to 
be  stored  in  the  node’s  state;  as  we  will  see,  it  is  assigned  only  as  part  of  our  observation  of 
the  node’s  behavior.)  The  specification  for  the  synchronization  is  as  follows: 

•  A  node  in  an  even  phase  may  enter  an  odd  phase  in  one  of  two  ways: 

-  It  may  announce  that  it  would  like  exclusive  access. 

—  It  may  see  that  some  other  node  has  entered  an  odd  phase. 

Note  that  an  odd  phase  does  not  start  until  some  node  wants  exclusive  access,  i.e.,  no 
polling  is  necessary. 

•  For  all  odd  k ,  no  node  enters  phase  k  +  1  until  all  nodes  have  entered  phase  k. 

t  For  all  odd  k ,  exactly  one  node  receives  exclusive  access. 

The  solution  we  propose  is  based  on  the  idea  of  a  priority  for  the  different  nodes,  where  the 
priority  is  used  to  resolve  competition  among  nodes  during  a  given  phase.  We  shall  initially 
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assume  that  each  node  has  a  distinct  priority,  but  after  discussing  the  solution,  will  discuss 
techniques  that  allow  the  assumptions  to  be  weakened.  A  priority  is  a  positive  integer. 
Values  exposed  along  arcs  will  be  non-negative  integers,  and  will  alternate  between  zero  and 
positive  values.  The  driving  idea  is  quite  simple: 

•  To  indicate  that  it  would  like  exclusive  access,  a  node  begins  the  propagation  of  its 
priority  throughout  the  graph. 

•  Nodes  with  higher  priority  that  are  not  interested  in  exclusive  access  during  this  phase, 
and  all  nodes  with  lower  priority,  assist  in  the  propagation. 

•  Eventually,  a  node  wanting  exclusive  access  will  detect  that  permission  has  been 
granted,  or  will  find  itself  overrun  by  a  higher  priority  propagation. 

There  are  probably  several  versions  of  a  propagation  algorithm;  the  one  presented  here  is 
based  on  a  simple  algorithm  for  marking  a  connecttd  component  of  a  graph.  A  node  is 
considered  “marked”  with  priority  l  if  it  is  exposing  /  ct:  an  arc.  A  node  wanting  exclusive 
access  attempts  to  put  its  priority  on  each  of  its  arcs,  thereby  marking  itself  with  its  own 
priority.  It  waits  to  see  whether  the  propagation  is  successful  and  eventually  finds  out 
whether  it  has  been  granted  access.  If  so,  it  can  perform  the  desired  action,  and  it  then 
releases  its  exclusive  access. 

To  make  all  of  this  completely  precise,  we  describe  the  set  of  states  for  an  activity 
description  d  and  the  definitions  of  a^i  and  r^. 

•  For  a  node  with  k  arcs,  its  state  will  be  a  k-tuple  of  triples,  each  consisting  of  two 
integers  and  a  flag,  denoted  Vijv'J ft. 

-  Vi  is  the  value  exposed  along  the  ?th  arc. 

-  v[  is  the  last  value  seen  in  a  transaction  with  the  ith  neighbor. 

—  If  Vi  ^  0,  then  /,■  =  1  if  during  this  phase,  the  neighbor’s  exposed  value  was  first 
to  become  equal  to  max(u,-,t;-);  otherwise  /,■  =  0. 

-  If  Vi  =  0  and  v\  ^  0,  then  /,•  =  1  perforce. 

—  If  Vi  =  0  and  v[  —  0,  then  /*  =  1  means  that  the  node  is  almost  ready  to  re-enter 
the  initial  state  (see  the  next  item). 

•  Initially,  a  state  is  (0/0/0 )j. 

All  of  the  activity  descriptions  will  be  the  same  except  for  variability  in  the  number  of  arcs, 
and  the  fact  that  each  d  has  an  innate  priority  Id. 

In  presenting  the  definition  of  rdi,  for  a  node  in  state  wo  shall  use  the  con¬ 

vention  that  /  =  maxj(max(u,,  v')).  Initially,  /  =  0  at  every  node,  and  in  this  graph  state 
the  following  transaction  is  the  only  way  for  l  to  become  positive  at  any  node. 

•  Td, *((0/0/0), 0)  =f  {(...,  fd/0/0, . . .)},  leaving  triples  other  than  the  ith  unmodified  (this 
convention  applies  in  all  definitions  of  transactions). 
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This  transaction  evidently  exposes  its  innate  priority  on  an  arc. 

Once  a  priority  is  exposed  on  an  arc,  a  neighboring  node  can  increase  its  value  of  l  with 
the  following  transaction: 


Td,i((vj/vj/fj)j>v")  =  {{•  •  •  . . .)},  where 


-  I  <  v f  (the  node  did  not  know  about  this  high  a  priority). 

These  are  the  only  two  transactions  that  can  increase  the  value  of  /  at  a  node. 

The  next  transaction  propagates  a  priority  to  a  neighbor  that  may  not  have  seen  it  yet. 


iMIfik’O  =  {(•••  ■  'K/o,  ■  •  •)) 


-  V{  <  l  (the  node  has  seen  a  higher  priority  but  not  exposed  it  on  this  arc). 

-  v"  <  l  (the  neighbor  may  not  know  about  priority  /). 


Suppose  we  apply  the  transactions  stated  thus  far  until  none  of  them  applies  any  more. 
Then  in  state  ( Vj/v'j / /,)_,-,  we  will  either  have  Vi  =  l,v[  <  l  and  /,•  =  0,  or  V{  <  fvj  =  l,  and 
fi  =  1.  The  latter  case  does  not  occur  in  the  node  whose  innate  priority  is  /,  and  occurs 
in  all  other  nodes  exactly  once  (on  the  arc  along  which  it  first  saw  /).  Imagine  orienting  all 
arcs  toward  the  end  where  f  =  1  (this  can’t  be  the  case  at  both  ends).  The  oriented  arcs 
form  a  spanning  tree  of  the  transaction  graph,  where  all  paths  in  the  tree  lead  toward  the 
node  whose  innate  priority  is  /. 

It  is  easy  for  the  root  of  the  tree  to  tell  that  it  is  the  root — it  is  the  only  node  where 
Vi  =  l  and  fi  =  0  for  all  i.  The  hard  part  is  this:  how  does  the  root  know  that  the  above 
transactions  have  been  done  until  none  of  them  is  possible?  Let  us  first  make  a  simplifying 
assumption  that  the  transaction  graph  is  a  tree.  Then  it  is  also  easy  for  every  leaf  to  tell 
that  it  is  a  leaf.  It  can  announce  that  propagation  can  go  no  further  by  exposing  l  on  the 
arc  where  /,  =  1.  When  nodes  further  up  the  tree  see  l  on  arcs  pointing  to  them,  they 
can  in  turn  expose  /  on  their  arcs  where  /,  =  1,  until  eventually,  the  root  node  sees  itself 
surrounded  by  /,  at  which  point  is  knows  it  has  excluded  all  other  nodes. 

Let  us  drop  the  assumption  that  the  transaction  graph  has  no  cycles.  If  the  above  strategy 
is  pursued,  a  block  arises  because  a  leaf  cannot  detect  that  it  is  a  leaf — it  may  still  see  values 
less  than  l,  specifically,  on  cycle  arcs.  But  cycle  arcs  are  fortunately  easy  to  detect — when  a 
node  sees  its  l  on  an  arc  where  v[  <  /,  it  knows  the  arc  is  involved  in  a  cycle,  and  to  break 
the  cycle,  exposes  l  on  it,  using  the  following  transaction 

•  T{(vi/v'j/fj)j 1 0  =f  {{•••>  ////l,  •••)}>  where 

-  v[  <  l  (the  node  knows  about  /,  but  l  arrived  at  this  neighbor  by  some  other 
route). 


Again,  suppose  we  apply  the  transactions  stated  thus  far  until  none  of  them  applies.  Then  in 
state  (vj/v'J ff)},  we  will  have  vt  =  l,v't  <  l  and  /,  =  0  (  the  arc  is  an  incoming  tree  arc),  or 
Vi  =  l,v'i  =  l  and  /,  =  0  (the  arc  is  a  cycle  arc,  which  we  also  call  incoming),  or  Vi  <  l,vl  =  / 
and  fi  =  1  (the  arc  is  an  outgoing  tree  arc),  or  v ,  =  l,v[  =  l,  and  /,  =  1  (the  arc  is  a  cycle 
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arc,  which  we  call  outgoing).  In  this  state,  a  leaf  of  the  spanning  tree  will  have  /,•  =  1  on  its 
outgoing  tree  arc,  and  all  other  arcs  (if  any)  will  be  incoming  cycle  arcs  on  which  the  leaf 
will  have  seen  /.  Thus  the  following  rule  will  cause  it  to  expose  l  on  its  outgoing  tree  arc. 

•  T((vj/vj/fj)j>  0  =f  {<•••>  •••)}>  where 

-  Vi  <  fv[  =  l  and  /,■  =  1  (/  not  previously  exposed  on  the  tree  arc). 

-  For  j  ^  i,  v'j  =  l  (all  other  arcs  are  cycle  arcs  or  incoming  tree  arcs,  and  have  been 
marked). 

This  rule  causes  /  to  propagate  up  the  tree,  and  eventually  the  state  of  every  node  becomes 
(/////i)i.  It  is  in  this  state  that  the  root  node,  where  l  =  /<*,  has  exclusive  access.  After  it  has 
done  its  business,  it  begins  setting  exposed  values  on  incoming  arcs  (there  must  be  at  least 
one)  to  0,  using  the  following  transaction,  which  also  is  partly  responsible  for  propagating  0 
against  the  imagined  direction  of  the  arcs: 

•  Td,i((vi/vj/fj)hl)  =f  {(•••> 0///1, ...)},  where 

-  Either  /  =  ld  or  v'-  =  0  for  some  j. 

-  Vi  =  /,  v[  =  /  and  /,-  =  0. 

-  For  all  j  ^  i,  Vj  =  l,  v'j  =  /  and  fj  =  0  (this  transaction  hasn’t  yet  happened), 
Vj  =  0,u'-  =  /  and  fj  =  1  (it  has  happened),  or  Vj  =  1  and  fj  =  1  (this  is  an 
outgoing  arc). 

To  trigger  this  transaction  in  nodes  other  than  the  root,  it  is  necessary  and  sufficient  to  see 
0  along  a  forward  arc. 

•  Td,i((vj/v'j/fj)j, 0)  =f  {(...,  // 0/1)},  where 

-  Vi  =  /,  v'i  =  /,  and  /,-  =  1 

Stabilizing  with  these  transactions  results  in  the  imagined  direction  of  arcs  going  from  an 
exposed  value  of  0  to  an  exposed  value  of  /. 

The  final  transaction  applies  when  a  node  has  seen  0  along  all  incoming  arcs;  it  then 
exposes  0  along  what  were  previously  considered  outgoing  arcs,  destroying  the  last  record  of 
the  orientation: 

•  ^{{vjlv'jlfj), 0)  d=  {(. . . , 0/0/1, ...)},  where 

-  Vi  =  l,  v'i  =  0,  and  /,■  =  1 

-  For  j  ^  i,v'j  =  0 

The  final  step  is  not  a  transaction,  but  an  out-of-graph  change  that  resets  the  state  to  the 
initial  one. 

•  »4(0/0/l>y)  t'  {(0/0/0)} 


35 


Transaction  Graphs 


Note  that  this  step  may  occur  and  subsequent  phases  begin  in  nodes  other  than  the  root 
before  the  root  has  entirely  reset  itself,  but  this  causes  no  harm,  because  once  an  arc  has 
the  iorm  0/0/1,  no  transaction  occurs  along  it  until  the  node  is  entirely  reset. 

We  close  with  the  promised  remarks  on  priority.  The  first  point  is  that  the  priority  need 
not  be  innate  in  the  activity  description  but  instead  can  be  part  of  the  state;  further,  the 
priority  relationships  do  not  have  to  be  the  same  from  phase  to  phase.  For  example,  if  n  is  the 
number  of  nodes  in  the  graph,  as  each  node  resets  itself  at  the  end  of  a  phase,  it  could  change 
h  to  Id  + 1  mod  n,  so  that  there  is  a  rotating  system  of  priorities.  Other  possibilities  include 
data  dependent  priorities  with  Id  used  only  as  a  tie-breaker.  Still  another  possibility  is  to 
use  probabilistically  computed  priorities,  accompanied  merely  by  a  unique  id,  and  in  those 
cases  where  two  nodes  happened  to  assign  themselves  the  same  priorities,  tolerate  a  certain 
probability  that  no  transaction  will  be  performed  during  a  phase.  The  point  here  is  not  so 
much  what  scheme  is  used,  but  that  the  scheduling  and  even  the  degree  of  indeterminacy  is 
in  the  hands  of  the  protocols,  not  of  the  system.  There  is  no  assumption  of  fair  scheduling, 
indeed,  we  can  assume  a  malicious  scheduler. 

4.6  Procedure-Based  Activity  Descriptions 

Suppose  we  have  procedure  f  that  takes  some  number  of  arguments  and  yields  some  num¬ 
ber  of  results.  We  explicitly  allow  f  to  perform  out-of-graph  communication,  for  example, 
accessing  and  updating  an  external  database.  In  this  section,  we  discuss  the  activity  de¬ 
scription  based  on  f .  The  idea  is  that  f  lives  inside  a  node  whose  incoming  arcs  both  supply 
some  of  the  arguments  and  determine,  by  being  enabled,  when  f  is  to  be  invoked.  Dually, 
the  outgoing  arcs  say  when  the  application  of  f  is  complete,  i.e.,  are  enabled,  and  may  be 
used  to  propagate  results  to  neighbors. 

In  a  parameterized  transaction  graph,  a  reasonable  convention  would  be  to  reserve  rect¬ 
angles  for  procedure-based  activity  descriptions,  thus  devoting  a  simple  shape  to  what  will 
probably  be  the  most  common  form  of  activity  description.  An  example: 

\  I  A 

y  x 

Revise  document:  u,v  *— f(v,y,  z,3) 
u  v 

TTT\ 

The  “Revise  document"  is  the  label  that  will  appear  on  the  corresponding  node  in  a 
participant’s  view  of  an  activated  graph.  Note  that  some  of  the  parameters  supplied  to  f  may 
be  local,  i.e.,  arc  labels;  others  may  be  non-local,  and  refer  to  parameters  of  the  containing 
parameterized  transaction  graph;  the  other  possibility  is  a  constant.  An  unlabeled  incoming 
arc  is  one  whose  only  contribution  is  the  fact  that  it  is  enabled;  more  information  than  that 
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about  the  arriving  value  doesn’t  matter.  Similarly,  the  value  sent  down  an  unlabeled  output 
arc  is  one  which  has  no  information  beyond  the  fact  that  it  is  sent. 

The  reader  may  have  noticed,  the  directed  arcs,  in  contrast  to  our  usual  assumption  that 
the  transaction  graph  has  undirected  arcs.  This  is  not  a  change  to  the  theory,  but  reflects  the 
fact  that  the  above  node  is  at  a  more  concrete  level  than  what  we  have  been  discussing — it 
is  what  might  actually  be  seen  in  a  graphical  display  of  a  parameterized  transaction  graph. 
Moreover,  the  directions  on  the  arcs  do  carry  meaning,  as  we  now  explain.  The  arcs  on  a 
procedure-based  activity  description  have  one  of  two  basic  forms  of  protocols,  “send”  and 
“receive”,  and  the  directions  of  the  arcs  indicate  which,  in  the  natural  way.  Let  us  suppose 
that  our  underlying  language  has  types.  The  protocols  are  given  by: 

•  send(t)  and  receive^),  where  (send(t))T  =  receive(f). 

The  protocols  specify  exactly  what  is  meant  by  “enabled”  (used  informally  above).  One  way 
to  do  this  is  as  follows: 

•  send «)  is  true  of  ((/,-, «;));  <&f 

-  If  ft  =  0,  then  V{  (the  value  being  “sent”)  is  either  (false,  nil),  indicating  that  the 
arc  is  not  enabled,  or  is  ( true,w ),  where  w  is  a  value  of  type  t ,  indicating  that  the 
arc  is  enabled. 

—  If  fi  =  1,  then  V{  (the  reply)  is  either  false  (ready  for  a  value  to  be  sent),  or  true. 

-  If  ((fi,Vi))i  is  reduced,  then  /,•  alternates  between  0  and  1  (once  a  value  is  exposed, 
it  is  held  until  a  change  is  seen),  and  the  sequence  of  (v,)t-  is  of  the  form: 

...  ( true,wi )  true  (false,  nil)  false  (true,w2)  true  (false,  nil)  ... 

It  is  not  necessary  to  define  how  receive (0  acts  as  a  predicate,  since  that  is  determined  by 
send(f). 

Earlier,  we  gave  an  informal  description  of  how  a  procedure-based  activity  description 
works.  We  now  state  more  precisely  how  one  works,  not  only  guaranteeing  the  behavior 
specified  by  the  above  protocols,  but  also  showing  the  details  of  how  inputs  and  outputs  are 
coordinated.  As  with  mutual  exclusion,  it  is  useful  to  think  of  one  of  these  nodes  as  going 
through  phases,  but  unlike  mutual  exclusion,  one  wants  to  decouple  behavior  of  nodes,  up 
to  the  necessity  of  coordinating  various  inputs  and  outputs. 

•  During  a  “transmit”  phase,  values  on  incoming  arcs  change  from  false  to  true,  ac¬ 
knowledging  (and  grabbing)  an  argument  value;  values  on  outgoing  arcs  change  from 
(false,  nil)  to  (true, . . .),  posting  a  result  value. 

•  During  a  “compute”  phase,  values  on  incoming  arcs  change  from  true  to  false ;  values 
on  outgoing  arcs,  from  (true, . . .)  to  (false,  nil).  Both  these  may  be  considered  “resets”. 

Let  (n;  :  receive (t,) ),  -  (n(  :  send (<()),/  be  the  protocol  for  a  procedure-based  activity 
description.  Then  the  state  has: 

•  A  value  on  each  arc  to  buffer  the  corresponding  argument  or  result,  denoted  xt  and  x[, 
respectively. 
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•  A  boolean  on  each  arc  to  control  communication  there,  denoted  6;  and  6;  for  the  two 
sets  of  arcs. 

•  A  single  boolean  to  record  compute/transmit  state,  denoted  c,  for  “compute”  when 
true. 

•  As  a  notation,  the  state  s  =f  (c)  *  ((bi,  a :,•}),•  *  ((&(•,  $;),•#) 

Exposed  values  are  controlled  by: 

•  <7{(s)  =  bi 

m  ,r'Md-2.f  if6i' 

'  \  (false,  nil)  otherwise 

Values  exposed  on  incoming  arcs  change  to  true  only  during  the  transmit  phase,  and  only 
when  an  available  value  is  seen: 

•  Ti(s,  ( true,W{ ))  =  {{. . .  ( true,u>i ) . . .)},  when:3 

-  c  is  false. 

-  bi  is  false. 

Dually,  this  is  also  when  values  exposed  on  outgoing  arcs  become  (true.xty: 

•  T-,(s,  false)  =f  {(. . .  (true,  £■,) ...)},  when: 

-  c  is  false. 

-  b\,  is  false. 

The  end  of  a  transmit  phase  is  made  official  by  the  following: 

•  o(s)  =f  {(true, . . .)}  when: 

-  c  is  false. 

—  For  all  i ,  6,-  is  true,  and  for  all  i' ,  b\,  is  true. 

The  reader  may  supply  the  transactions  that  reset  the  arcs  during  a  compute  phase.  The 
end  of  the  compute  phase  is  marked  by  the  change  of  state  due  to  the  application  of  the 
procedure,  here  called  /. 

e  o(s)  =  {(false)  *  ((b{, x *  ((bi,x") ),v}  when: 

-  c  is  true. 

—  For  all  i,bi  is  false  and  for  all  i' ,b\,  is  false. 

-  ( x denotes  the  results  of  applying  /  to  (a 

3We  follow  a  convention  throughout  that  only  change  is  indicated,  in  this  case,  to  the  values  6,,x,. 
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Observe  that  this  does  not  change  values  on  outgoing  arcs,  in  spite  of  the  fact  that  it  changes 
x (■,  because  b\  is  false. 

We  can  summarize  the  results  of  the  above  discussion  by  giving  our  first  example  of  a 
parameterized  activity  description. 

•  procedure-based-activity-description 

string  list(name  x  type)  procedure  list(name  x  type)  — *  activity-description 

-  The  string  supplies  the  label  for  the  participant’s  view. 

-  Let  ({ n,-,ft))}-  and  {(nj-,  <'•)),■  be  the  two  list(name  x  type)  arguments.  Then  the 
procedure  argument  takes  arguments  of  types  {£'■/);<. 

—  The  signature  for  the  result  is  (n,- :  received, ■  )),■*  (n'-  :  send (£(•)).■'• 

-  The  state  and  the  functions  cr,  r,  and  o  are  described  above. 

The  reader  may  worry  that  in  procedure-based-activity-description,  the  procedure 
argument  /  must  exactly  match  the  signature,  while  in  the  discussion  of  the  graphical  rep¬ 
resentation,  there  is  a  looser  connection  between  f  and  the  incident  arcs.  This  discrepancy 
is  handled  by  a  translation  step  which  produces  /  from  f . 

Let  us  consider  a  procedure- based  activity  description  with  no  incoming  arcs,  initalized 
with  c  —  true  and  b[,  =  false.  Then  the  only  change  of  state  will  come  from  having  applied  / 
and  thereby  computed  which  are  then  propagated  along  outgoing  arcs.  Once  this  has 

happened  and  the  arcs  are  all  reset,  the  compute  state  is  re-entered,  and  /  is  re-invoked.  In 
other  words,  such  an  activity  description  will  invoke  /  as  often  as  it  can,  up  to  the  rate  at 
which  its  results  are  absorbed  and  it  can  supply  them.  This  is  ideal  for  generating  repeated 
events,  but  not  so  good  when  we  want  an  “initialization”  node,  whose  procedure  is  invoked 
just  once  at  the  beginning  of  an  activation.  One  could  construct  a  procedure  which  delayed 
forever  the  second  time  it  was  invoked,  but  this  seems  artificial,  and  initialization  is  common. 
In  the  interests  of  conciseness  of  graphs,  it  might  be  reasonable  to  introduce  a  second  kind 
of  parameterized  activity  description,  a  slight  variant  on  the  previous. 

•  procedure-based-activity-description-initialize 

string  procedure  list(name  x  type)  — >  activity-description 

-  The  arguments  are  the  same  as  before,  with  the  omission  of  those  for  incoming 
arcs. 

-  The  state,  cr,r,  and  o  are  also  the  same  as  before,  except: 

*  c  is  omitted  from  the  state,  and  in  the  values  for  r  given  previously,  the 
condition  on  c  is  omitted. 

*  The  rule  for  o  that  sets  c  to  true  is  dropped. 

In  the  spirit  of  using  a  distinct  shape  for  each  primitive  parameterized  activity  description, 
the  above  might  seen  in  parameterized  transaction  graphs  as: 
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Dually,  nodes  which  are  expected  to  see  exactly  one  phase  of  input  might  be  drawn  thus: 


Consider  a  graph  that  has  initialization  and  termination  nodes,  and  where  all  nodes  with  both 
incoming  and  outgoing  arcs  have  procedure-based  activity  descriptions.  Consider  further  the 
case  in  which  the  graph  is  acyclic  and  in  which  it  is  possible  to  assign  a  number  to  each 
node  which  corresponds  to  how  long  the  procedure  takes,  once  it  arguments  are  ready.  Then 
we  have  a  classic  pert  chart,  and  can  use  well-known  techniques  to  do,  say  critical  path 
analysis.  Such  an  analysis  is  not  deep  of  course,  but  the  point  is  that  this  is  a  simple 
example  of  tying  a  transaction  graph  to  an  analysis  tool.  Transaction  graphs  are  integrated 
into  the  everyday  activities  of  its  users,  and  thus  provide  a  way  of  connecting  the  activities 
of  its  users  with  analysis,  for  example,  monitoring  whether  the  assumptions  of  the  analysis 
become  inconsistent  with  reality. 

Suppose  that  a  transaction  graph  consists  entirely  of  procedure-based  activity  descrip¬ 
tions,  and  allow  the  graph  to  have  cycles.  Then  the  execution  of  a  graph  corresponds  to  a 
“firing  sequence”  in  a  marked  graph,  a  subclass  of  Petri  nets,  studied  extensively  in  [HC69]. 
There  are  a  variety  of  analysis  techniques,  including  liveness  (deadlock-free-ness),  maximum 
cyclic  rates,  and  peak  resource  usage.  As  with  the  connection  to  pert  charts,  transaction 
graphs  provide  a  connection  between  useful  analysis  techniques  and  the  actual  progress  of  a 
real  activity. 

In  both  the  above  examples,  it  should  be  remembered  that  it  is  not  necessary  that  the 
detailed  transaction  graph  used  to  coordinate  everyday  activities  be  precisely  of  the  form 
required  by  the  analysis  technique.  It  is  more  likely  that  there  is  a  projection  that  takes  the 
detailed  transaction  graph  to  a  graph  that  lies  within  the  class,  so  that  the  analysis  applies 
to  a  particular  view  of  the  activity,  as  one  would  expect. 
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A  The  Universal  Activity  Description  for  a  Protocol 

We  show  that  for  any  protocol  p ,  there  exist  5P,  crp,  tp,  and  op,  which  together  with  the 
signature  (n  :  p)  comprise  an  activity  description  dPi„  with  the  following  property: 

•  For  any  activity  description  d  with  signature  (n  :  p),  there  is  a  projection  from  d  to  dp<n. 

Because  of  the  generality  of  this  result,  in  particular,  the  fact  that  p  can  be  an  arbitrary 
predicate,  the  proof  we  give  is  non-constructive — it  does  not  say  how  to  implement  dp<n.  In 
practice,  this  is  usually  not  difficult,  but  even  if  it  is,  the  result  says  to  keep  trying,  because 
the  solution  exists. 

The  almost  right  idea  for  an  element  of  <SP  is  a  sequence  of  pairs  (fi,v  1), . . . ,  (fk,  Vk)  for 
which  p  holds  and  which  ends  with  fk  =  0.  In  this  “state”: 

•  <Tp(({/«')ui))f=  1)  would  be  defined  to  be  v*. 

•  tp(({/«)  v«))Li)  would  be  defined  to  be  the  set  of  all  sequences  (( /,',*>,• ))f=i  where: 

-  p  holds  for  (f[ ,  uj), . . . ,  (//,  vj)  and  //  =  0  (otherwise  this  would  not  be  a  legitimate 
state). 

-  The  new  sequence  is  an  extension  of  the  original,  i.e.,  /  >  k  and  //  =  fi  and 
v\  =  Vi  for  i  =  1, . . . ,  k.  Thus,  we  may  drop  the  primes  from  f-  and  v\. 

-  The  new  sequence  does  not  skip  any  transactions  at  the  node  in  question,  i.e., 
/,-  =  1  for  i  =  k  +  1, . . . ,  /  -  1.  (If  /  =  k  +  1,  this  is  a  vacuous  condition.) 

-  The  new  sequence  is  compatible  with  the  value  seen  by  t,  i.e.,  :  v  =  u,-0  where 

i0  =  max{i  <  / 1  /, ■  =  1}.  (If  /,-  =  0  for  all  i,  this  is  vacuous.) 

The  motivation  behind  this  definition  was  stated  earlier:  rp  responds  to  a  sequence  of  trans¬ 
actions  in  a  legal  way,  and  it  will  respond  to  any  legal  sequence,  i.e.,  is  unpredictable  up 

to  the  constraints  imposed  by  p.  The  only  reason  that  it  is  not  quite  right  is  that  a  state 

“remembers”  too  much:  a  sequence  of  states  in  an  execution  that  we  wish  to  project  may 
repeat,  but  states  in  the  above  definition  of  r  always  grow  longer  and  thus  never  repeat. 
Hence  we  cannot  obtain  a  projection. 

This  flaw  can  be  remedied  by  using  as  states,  i.e.,  elements  of  Sp,  not  sequences  of  the 
above  form,  but  rather,  quotient  sets  of  sequences  of  the  above  form,  under  the  following 
equivalence  relation: 

•  For  j  =  1  and  2,  let  t,-  =f  ((/o>u»'i))f=i‘  We  will  assume  that  p  holds  for  tj  and  that 
fk3j  —  Q.  We  define  t\  ~  t2 

-  Vklti  =  Vk2l2  (both  “states”  expose  the  same  value). 

-  For  any  t0,  p(t\~to)  %£p{t2*to)  (where  *  means  concatenation). 

Intuitively,  p  can’t  tell  the  difference  between  ti  and  t2. 


41 


